5 ms·
If only developers learned more about the DB engines they use and their capabilities. I've seen so many bone headed decisions (EAV "schemas" being a recurring
by acveilleux 10y ago
If only developers learned more about the DB engines they use and their capabilities.
I've seen so many bone headed decisions (EAV "schemas" being a recurring one) because it was easier to program around the DB than learn how to use it proper. It's not because a few classes insulate you from the bone headed SQL that it's a good idea.
- zer00eyz 10y agoEAV isn't all bad, there are use-cases for it. If you have a highly dynamic data (user configurable) then EAV might be a good way to STORE that data. Is it ugly, it sure is. Moving read out to a cache layer, and search out a purpose built system, the DB becomes a persistence engine. You have solved the other issue you don't mention with EAV, and thats performance. Edit (my ability to post should be forbidden till I have had coffee, cleaned up for clarity)
- acveilleux 10y agoMost EAV implementations I've seen had under 10 distinct "schema-less" virtual tables (sorry about lack of terminology) with perhaps 40-60 distinct "columns" and the different variations of a record types usually had consistent attributes. Basically the whole thing could've been replaced by 5-10 tables. Maybe taking advantage of Postgres OORDBMS capabilities for the common columns. Queries tended to group complex CTEs and multiple self-joins. You know it's an anti-pattern when devs start complaining about postgres join performance and you see they got two tables being joined 15 times...
- tajen 10y agoI've made a product which uses Postgres' unique capabilities (It's the only one with transactions covering DDL). Side-effect: Not supporting all DBMS is a no-no when you need funding/convincing anyone. Hence the lowest-common-denominator race for most software. Mine is doing well, thank you ;)