3 ms·

> But if you are writing for 1200 tables Have you ever managed 1200 "live" (in-development) tables on a SqlAlchemy app? That is impressive. Not only because o

> But if you are writing for 1200 tables Have you ever managed 1200 "live" (in-development) tables on a SqlAlchemy app? That is impressive. Not only because of the amount of work that entices, but also because you can just read the schema and provide a dynamic object representation of it (think dataclasses, but based on a table schema). Also, if you're querying 1200 tables, python might not be such a good idea. Impedance mismatch at a language level. > boilerplate code for 1200 classes, yes that's kind of ORMish Yes, please do explain how a Python ORM can save you from having 1200 classes you need to maintain, plus the need for specialized queries.

zzzeek 3y ago
Not personally but we absolutely have users dealing with 1000+ table databases . SQLAlchemy includes mass reflection and dynamic mapping features and there are also extensions like SQLACodeGen that generate mappings as python source code. Additionally, its not unreasonable that applications within an organization are composed such that they refer only to a particular segment of such a database, but across the organization there is source code that refers to the database as a whole in the aggregate.