3 ms·
Looks like a schema to allow the code to decide the real schema at runtime. A poor mans mongodb.
by quickthrower2 8y ago
Looks like a schema to allow the code to decide the real schema at runtime. A poor mans mongodb.
- platz 8y agoThis is only a slight exaggeration of real things that exist in products like SharePoint or Visual Studio Team Services
- rco8786 8y agoThis is pretty common looking for things like CRMs or CMSes where customer specific custom fields rule the day.
- CMCDragonkai 8y agoThe database was meant to be the CMS and SQL was designed to be human readable.
- josephg 8y agoCounterpoint: If small design decisions require global SQL schema changes, it slows you down. And small barriers to change will, in aggregate, kill you. Eg, over a month of iterations: "Can we add another field to user registration? It should be free text. Oh, they should select from a list. No wait, make it a date. Actually a date and a text field. No wait, dump the text field." Sometimes slowing down these changes is a good thing. But often, being able to ship each iteration along the way will help your design team converge on the best solution. If you need to write a schema migration for every iteration, it kills the ability of your team to experiment and explore the space of "what should our product actually look like". Faster iterations = more iterations = better product in the long term. Sometimes the best long term result requires some random stuff getting crammed into a big JSON field in your database in the short term.
- enimodas 8y agoSounds like the real problem is that there's too much friction with schema migrations.