This reminds me of a similar horror story involving "the ultimate database design" https://www.simple-talk.com/opinion/opinion-pieces/bad-carma...
There's also the "second system effect", where the creator tries to avoid all of the bad things they encountered in the first system, and implement every spur-of-the-moment idea they ever had, all at once.
The first mention of JDSL is a link to an article about it: http://thedailywtf.com/articles/The_Inner-Platform_Effect
Similarly, sometimes it's useful to provide just enough primitives that a "non-programmer" can be trained on how to perform a very constrained set of operations on the data they deal with, and provide them with a simplistic language that funnels them into the types of operations they are most likely to want and away from (or disallowing) operations that are deemed problematic or complex.
The issue is that these options are usually not what you want to do. Not because they are wrong, but because they are much more likely to result in something worse, given the possible outcomes. Usually, the result is multiple of the following: too late, too slow, too complex, too inefficient, too hard to maintain, too hard to develop. That said, given a fairly lax timetable, smart people to design and develop the system with, and a clear vision of what needs to be accomplished, great things can be accomplished. But how often to do we get all that at once?
I think these kinds of things are great learning experiences, I'm just glad that abomination of mine was never released.
Sometimes this works a lot better that you might expect and the platform works pretty well, sometimes it produces Cthulhu level nightmares.
NoSQL sort of legitimized these kind of bad practices.
I've seen those sort of things all over the place in every NoSQL project I've ever worked on.
It is a relational "design pattern" used to implement a database inside a database, instead of using the database itself as it was designed to be used.
This has all sorts of fun (not) and useful (neither) effects, including: worsened performance; inability to ensure data integrity through constraints; bloated / unreadable queries; hard to find bugs; needlessly complicated migrations; and so on.
For example, Firefox extensions could be easily considered an inner platform but they have the benefit of providing a platform which is safer and more extensible than the underlying OS.
Likewise, EAV provides a poor functional replacement for an actual database. But they also prove a lower curve for implementing very simple extensions and limit the capacity for trivial mistakes. Speaking from experience, it's the WordPress sites where plugins have created a whole bunch of extra poorly-built tables that worry me most.
`wordpress_%app_table1` etc. if you want to do it ad-hoc.
PostgresSQL support namespacing out of the box[1][2].
[1] https://www.postgresql.org/docs/9.3/static/ddl-schemas.html
[2] http://jerodsanto.net/2011/07/building-multi-tenant-rails-ap...
Granted one is more dangerous than the other, but to me it's no reason to give them access. It's still a headache.
If only the developers have access to modify the structure, the way it is done is not important (it can be done through a webform that alters a database, though the addition of a json definition, through coding, etc.) After all, you can modify the schema through PHPMyAdmin. It's some kind of admin interface. You just don't grant your users the right to do it. Just as you don't grant them the right to add custom fields, unless they know what they are doing, which is seldom the case :)
I think that EAV gives a false sense of security, in that it does not "break" much if done by a non-knowledgable user. But still, if it is done badly, good luck reconciling the data.
It's certainly true that life is easier if you never implement certain kinds of features but at that rate why make a program at all?
I disagree strongly here and see this attitude a lot. It's easy to say "not my problem, you fucked it up, you fix it" but that is a very customer-hostile attitude.
Instead we should be giving users functionality they want in a way that prevents them from screwing things up through a combination of feedback and constraints. Sure, if a user types in blatantly incorrect data there's not much you can do. But you can do a lot more than say "here's a narrow ledge and a pit of snakes, if you fall in it's not my fault". This just results in unhappy customers who don't care whose fault it is, all they know is that your software ate their data.
Very in agreement here. Almost without fail, if they knew enough how to 'fix' it, they wouldn't have fucked it up in the first place.
Much of this attitude depends on org structure. Are you talking about paying end-customers? Or joe in accounting 3 doors down who consistently never follows any directions you give him re: data?
Of course, it's worth remembering that real databases do not typically use an EAV storage pattern for their data, so maybe it's not the only way to model a custom data store within a relational system.