The pictures are necessary when: 1) you do a brainstorming. doing it the visual way is much slower than the markup way. personally done it dozens if not hundre

The pictures are necessary when: 1) you do a brainstorming. doing it the visual way is much slower than the markup way. personally done it dozens if not hundreds of times with seq.diagrams. actually started donating to this guy who created sequencediagram.org, he saved me hours 2) you need to communicate chunks of the design with non-technical personnel such as business analysts and folks who have no clue about normal forms, outer joins, relational or hybrid designs, etc. they understand much better with visual assistance, which is in essence - suggestopedic approach (https://en.wikipedia.org/wiki/Suggestopedia https://en.wikipedia.org/wiki/Suggestopedia). and you know what - they never admit their lack of fundamental knowledge, which is even worse than not explaining the matter at all. bpmn and seq.diagrams work very well here, and of course - all 1910s flowchars should be forbidden. 3) when there's a large volume of intertwined entities. you just can't convince me that a graph is better represented as series of relational-algebra-alike texts, and not a planar image of it. try to imagine what the Northwind educational DB looks like as text ... and how you teach/explain to s.o. to walk it. https://support.microsoft.com/en-us/office/northwind-database-diagram-cd422d47-e4e3-4819-8100-cdae6aaa0857 https://support.microsoft.com/en-us/office/northwind-databas...