3 ms·

There's a difference between cardinality when it comes to databases (essentially cardinality in modelling vs cardinality in data). Cardinality in modeling (rel

There's a difference between cardinality when it comes to databases (essentially cardinality in modelling vs cardinality in data). Cardinality in modeling (relationship cardinality) refers to your relationship type i.e. 1:1, 1:M, M:M Cardinality w.r.t. data refers to how many unique values a particular column can have. e.g. a Primary Key has high cardinality because every row has a unique value. A boolean flag has low cardinality because it only has two values. TBH, I'm not 100% sure which one the OP is talking about here because you need to factor in number of joins and indexes etc, but from the perspective on relationship cardinality, you can think of some of the common differences in modelling for OLTP ("real time" databases) and OLAP (data warehouse etc). The former would generally have smaller tables and more joins, while the latter would usually have relatively massive tables which inherently could imply fewer joins, but this is often not the case. It just depends on your system and use-case.

danpalmer 4y ago
A bit late, but what I meant was that: With complex data but not too much of it, going all in on relational modelling makes development much easier, more reliable, and databases are perfectly capable of handling the necessary joins. With lots of data that isn’t too complex, denormalising a little and not using as many joins, or using a DBMS that doesn’t have joins and denormalising a lot (E.g. Redis, Cassandra, etc) will work well. Most problems are one or the other, or can be refactored into one or the other. At a previous job, we went hard on the relational aspect, and it worked well almost all the time. Inventory management, order management, user accounts, internal processes, etc. The main place it broke down was one table (out of ~450) of user content that due to the way the product worked, represented about 50% of our data. Working with that table became very hard. The right move would have been then to remove it and use a more appropriate DBMS, abandoning the heavily relational design for just that part.

danpalmer 4y ago

A bit late, but what I meant was that: With complex data but not too much of it, going all in on relational modelling makes development much easier, more reliable, and databases are perfectly capable of handling the necessary joins. With lots of data that isn’t too complex, denormalising a little and not using as many joins, or using a DBMS that doesn’t have joins and denormalising a lot (E.g. Redis, Cassandra, etc) will work well. Most problems are one or the other, or can be refactored into one or the other. At a previous job, we went hard on the relational aspect, and it worked well almost all the time. Inventory management, order management, user accounts, internal processes, etc. The main place it broke down was one table (out of ~450) of user content that due to the way the product worked, represented about 50% of our data. Working with that table became very hard. The right move would have been then to remove it and use a more appropriate DBMS, abandoning the heavily relational design for just that part.