Uh . . .ORM, as in NHibernate, does exactly what you talk about building. Given a bunch of classes, it generates the table schema. Not only that, it provides you with a manager object that you use to save, query and delete objects. It enforces all of your constraints. Manager.Save(obj). Manager.Find(type, id). Manager.FindAll(type, string). Manager.Delete(obj). You get the idea. All of the tables, columns, relationships, dependencies and constraints are marked up in code as .NET attributes. You never need to write a single line of SQL unless you want to optimise a particular query (in which case, the ORM tool will happily use your supplied one). Furthermore, the ORM layer provides a distributed runtime cache, which it flushes on its own schedule (all configurable of course) so that half the time you never even HIT the database when making a query. ORM wins EVERY TIME, if you ask me. There's a bit of a learning curve, to specify the mappings so the tool does what you want. After that, it's a programmers dream. Just don't expect to make friends with any DBAs after you start advocating for it :-) All of the disadvantages you have listed simply don't apply in the ORM world. That's the whole point. I think you're thinking of code generation.