> I’ve found that reflection techniques to get the data definition are not worth it and I succumb to managing the redundancy of data definitons in two places.
Not sure if much has changed regarding the "reflection techniques" since 2014, but I think Postgres does a fine job reflecting. (Don't know much about others)
For example my favorite library Massive.js (a data mapper) depends completely on reflection. It allows its users to access tables, views, functions, extensions, and even enum types from its Javascript API, without the need for models. This completely solved the data definition redundancy problem for me.
I even made a small layer on top of it to get the constraint information too using the information_schema, and everything is working like a charm.
Not sure if much has changed regarding the "reflection techniques" since 2014, but I think Postgres does a fine job reflecting. (Don't know much about others)
For example my favorite library Massive.js (a data mapper) depends completely on reflection. It allows its users to access tables, views, functions, extensions, and even enum types from its Javascript API, without the need for models. This completely solved the data definition redundancy problem for me.
I even made a small layer on top of it to get the constraint information too using the information_schema, and everything is working like a charm.