That's not "visualizing database", that is "visualizing database interactions", which is a completely different beast. Visualizing databases help scope the domain, visualizing interactions help scope the workload type. And they may or may not be within the realm of the same process.
Also, starting from top to bottom, most of the examples are actually too simplistic to be taken into account - when you have "user writes post" (I'm not even going to nitpick how that translates in your example to a select instead of an insert, but lets assume its not a user story), you are discarding context on purpose - user writes post WHERE? his timeline? a group? is it a comment post?
Is this relevant? Yup, because the simplistic graph examples don't work when you have a multi-level structure where you're posting to, or conditional rules to actually allow posting. Thing is, in *real life* you will often have database schemas (maybe visually), AND business rules, mapped independently, not this mish-mash. If you think I'm wrong, pick a simple social network (like eg. twitter) and try to map it using your approach, with consistent results.
sorry I had to take some time out before responding.
> I'm not even going to nitpick how that translates in your example to a select instead of an insert, but lets assume its not a user story
Yes, this is not a user story. It's funny, I started to think about inserts only after your comment. I've spent couple of years just glossing over it, like yeah. somehow the data gets into the database, not a big deal.
More important, re "nitpick". I think that if you want to nitpick then this is a completely wrong time and place (same for "not visualizing database but visualizing database interactions". Minimal Modeling is absolutely in the early adopters phase, it's like a toddler. Nitpicking is counterproductive, so I'm heavily discounting any attempts. Of course, big valid counter-examples are welcome.
> most of the examples are actually too simplistic to be taken into account
I'm not sure if I understand what "simplistic" here means. Each link (each arrow) is the minimal element of the database schema, by definition. Taken together, several such links and attributes handle some sort of a workflow (like, what happens in the database after the user clicks "Post" button).
> discarding context on purpose - user writes post WHERE? his timeline? a group?
I wouldn't the context is discarded: "WHERE" is explained right below, in the following section.
The thing is that even in Mokum's codebase those two things: "Post and around it (user-visible content)" and "Timeline structure of the post (permissions and visibility)" are pretty cleanly separated.
> the simplistic graph examples don't work when you have a multi-level structure
Absolutely. But it would be weird to begin an explanatory article with multi-level structure and conditional rules, wouldn't it?
> If you think I'm wrong, pick a simple social network (like eg. twitter) and try to map it using your approach, with consistent results.
I'm not sure if you would believe me (or maybe we're talking about different things), but it's interesting that you chose Twitter for "real life" and non-"simplistic" example. Twitter schema is strictly simpler than Mokum's. I mean, surely there are orders of magnitude more of technical complexity behind Twitter, but the primary data structure is simpler (if we're talking about the social networking part: there is certainly a lot in ads backoffice and in the payments, but those are hard to model as a black box).
I was going (been planning it for a few months already) to make a public Zoom webinar and just model Twitter (the user-visible social network part of it). January 16th maybe.
> Nitpicking is counterproductive, so I'm heavily discounting any attempts.
There is a big difference between focusing on overall structure and abstracting so much the representation becomes a deficient representation of reality. Your example is the latter, not the former. I really don't get the "hate" people have for detail - it is perfectly possible to design an outline for an actual feasible implementation, and I believe it is counter-productive training developers to do otherwise - context matters when modelling databases, because it defines both the boundaries and the workload types.
> Absolutely. But it would be weird to begin an explanatory article with multi-level structure and conditional rules, wouldn't it?
An explanatory article on database visualization? No, it wouldn't be weird at all. The Northwind database sample is still widely used because of that. Providing an actual multi-level relational example is quite closer to a real-life example. In fact, it is so relevant, that even MS Access came with a proper multi-level example.
> Twitter schema is strictly simpler than Mokum's.
I actually chose Twitter because is probably the simplest example you can find. And no, its not simpler than your example; I could go on on how most social networks are variations of directed acyclic graphs, and that twitter is not exception - and if I recall correctly, there is no place in your example where you're showcasing nested structures, or "leaf actions" (such as writing a post) that come from different user interactions (1. making a tweet; 2. replying to a tweet).
In the case of eg a twitter-like platform (that again, from an engineering perspective is actually a simple example), these different user interactions may land in completely different databases based on a specific set of criteria (stuff that your approach also doesn't map), such as geographic region, type of parent node and popularity. Obviously, following an extreme simplification approach, you can map everything to a flat table, but the issue still stands - the same generic action is triggered by different context operations. Mapping this visually in a way that is useful for database modelling is (to my understanding) anything but user-friendly.
> but the primary data structure is simpler
It maps the (partial) behavior of a DAG. Its not simpler than your example, and while it is a solved problem, specific implementations have specific trade-offs at scale (millions to billions of nodes), that - again - condition the overall design of the specific database implementation. Other social networks tend to be quite more sophisticated in their social graph. How sophisticated, you may ask? Have a look at this article - https://www.facebook.com/notes/10158791582247200/)
Quick note - I have no affiliation with twitter, and I don't even have a twitter account. Its just a simple example of a social network most people can identify with.
That's not "visualizing database", that is "visualizing database interactions", which is a completely different beast. Visualizing databases help scope the domain, visualizing interactions help scope the workload type. And they may or may not be within the realm of the same process.
Also, starting from top to bottom, most of the examples are actually too simplistic to be taken into account - when you have "user writes post" (I'm not even going to nitpick how that translates in your example to a select instead of an insert, but lets assume its not a user story), you are discarding context on purpose - user writes post WHERE? his timeline? a group? is it a comment post?
Is this relevant? Yup, because the simplistic graph examples don't work when you have a multi-level structure where you're posting to, or conditional rules to actually allow posting. Thing is, in *real life* you will often have database schemas (maybe visually), AND business rules, mapped independently, not this mish-mash. If you think I'm wrong, pick a simple social network (like eg. twitter) and try to map it using your approach, with consistent results.
Hey,
sorry I had to take some time out before responding.
> I'm not even going to nitpick how that translates in your example to a select instead of an insert, but lets assume its not a user story
Yes, this is not a user story. It's funny, I started to think about inserts only after your comment. I've spent couple of years just glossing over it, like yeah. somehow the data gets into the database, not a big deal.
More important, re "nitpick". I think that if you want to nitpick then this is a completely wrong time and place (same for "not visualizing database but visualizing database interactions". Minimal Modeling is absolutely in the early adopters phase, it's like a toddler. Nitpicking is counterproductive, so I'm heavily discounting any attempts. Of course, big valid counter-examples are welcome.
> most of the examples are actually too simplistic to be taken into account
I'm not sure if I understand what "simplistic" here means. Each link (each arrow) is the minimal element of the database schema, by definition. Taken together, several such links and attributes handle some sort of a workflow (like, what happens in the database after the user clicks "Post" button).
> discarding context on purpose - user writes post WHERE? his timeline? a group?
I wouldn't the context is discarded: "WHERE" is explained right below, in the following section.
The thing is that even in Mokum's codebase those two things: "Post and around it (user-visible content)" and "Timeline structure of the post (permissions and visibility)" are pretty cleanly separated.
> the simplistic graph examples don't work when you have a multi-level structure
Absolutely. But it would be weird to begin an explanatory article with multi-level structure and conditional rules, wouldn't it?
> If you think I'm wrong, pick a simple social network (like eg. twitter) and try to map it using your approach, with consistent results.
I'm not sure if you would believe me (or maybe we're talking about different things), but it's interesting that you chose Twitter for "real life" and non-"simplistic" example. Twitter schema is strictly simpler than Mokum's. I mean, surely there are orders of magnitude more of technical complexity behind Twitter, but the primary data structure is simpler (if we're talking about the social networking part: there is certainly a lot in ads backoffice and in the payments, but those are hard to model as a black box).
I was going (been planning it for a few months already) to make a public Zoom webinar and just model Twitter (the user-visible social network part of it). January 16th maybe.
Thanks,
> Nitpicking is counterproductive, so I'm heavily discounting any attempts.
There is a big difference between focusing on overall structure and abstracting so much the representation becomes a deficient representation of reality. Your example is the latter, not the former. I really don't get the "hate" people have for detail - it is perfectly possible to design an outline for an actual feasible implementation, and I believe it is counter-productive training developers to do otherwise - context matters when modelling databases, because it defines both the boundaries and the workload types.
> Absolutely. But it would be weird to begin an explanatory article with multi-level structure and conditional rules, wouldn't it?
An explanatory article on database visualization? No, it wouldn't be weird at all. The Northwind database sample is still widely used because of that. Providing an actual multi-level relational example is quite closer to a real-life example. In fact, it is so relevant, that even MS Access came with a proper multi-level example.
> Twitter schema is strictly simpler than Mokum's.
I actually chose Twitter because is probably the simplest example you can find. And no, its not simpler than your example; I could go on on how most social networks are variations of directed acyclic graphs, and that twitter is not exception - and if I recall correctly, there is no place in your example where you're showcasing nested structures, or "leaf actions" (such as writing a post) that come from different user interactions (1. making a tweet; 2. replying to a tweet).
In the case of eg a twitter-like platform (that again, from an engineering perspective is actually a simple example), these different user interactions may land in completely different databases based on a specific set of criteria (stuff that your approach also doesn't map), such as geographic region, type of parent node and popularity. Obviously, following an extreme simplification approach, you can map everything to a flat table, but the issue still stands - the same generic action is triggered by different context operations. Mapping this visually in a way that is useful for database modelling is (to my understanding) anything but user-friendly.
> but the primary data structure is simpler
It maps the (partial) behavior of a DAG. Its not simpler than your example, and while it is a solved problem, specific implementations have specific trade-offs at scale (millions to billions of nodes), that - again - condition the overall design of the specific database implementation. Other social networks tend to be quite more sophisticated in their social graph. How sophisticated, you may ask? Have a look at this article - https://www.facebook.com/notes/10158791582247200/)
Quick note - I have no affiliation with twitter, and I don't even have a twitter account. Its just a simple example of a social network most people can identify with.