Re:Highly opinionated SQL schema design to put you on the fa...
by fogzen on Monday May 01, 2023 @01:10AM
(#35769305)
I personally think it’s safer to enforce data constraints in application code, because “bad” data won’t break it. Putting the constraints in the database means your application is coupled to whatever database you use. Worse, because databases only offer a small set of constraints, it’s often the case that constraints are split between the database and application code. You have “validations” in both the application code and database definitions, and data must be checked/transformed anyway whenever it is marshaled to and from the database. Constraints in the database are effectively implicit, living in a set of migrations or often not part of any source control.
EAV indexing is much easier, because EAV is naturally represented as a tree. The whole database is the index. You only have four universal indexes that cover every query: EAV, AEV, AVE, and VAE. The mutual likes example above is covered by these indexes. And you never had to worry about it!
See Datomic for real world example of an EAV architecture.
On the more technical side, I don't know if Postgres would handle this efficiently. The `attribute` col has the classic low-cardinality problem for indexes. The one big table you use would have many very different access patterns. There are DBMSes more designed for this use case.
I'm also not seeing very much EAV adoption mentioned on Wikipedia. I can see this working for some specialized use cases, though. Has this worked well for you in the past?