3 ms·

> For what it's worth, Django models and doing good relational design solve a huge number of problems. I agree, but the main demand for something like this is

> For what it's worth, Django models and doing good relational design solve a huge number of problems. I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. It is very much a hack-- the technical debt of it just gets kicked down the road for someone else to correct, the first of which is the unfortunate analyst who used to churn out weekly reports with a handful of SQL statements but now has to run an entire ETL pipeline/data science marathon to correct all the inconsistencies.

danpalmer 8y ago
> I agree, but the main demand for something like this is going to be a client who wants to create their own forms on demand without touching Model code. I can see the use-cases, but I think that level of dynamism should be built into the data model, not built by building a dynamic data model. To take an extreme example, if you had a single table with the columns "key" and "value", you'd be able to encode any structure you wanted at the application level. This would likely be a bad idea (at least for general purposes), but there are levels in between that would work. Models like "Form" and "Form Item", and maybe even "FormItemType" and "FormItemField", things like that, could represent fairly complex dynamic structures.