For years I have dinked with and now considering making it into a real project.

I am thinking about developing a 'driver' of sorts that sits on top of RDMS( oracle, MSSQL, MySQL - others to follow). That given a table description the driver creates stored procedures and client code example(s) (front-end, back-end, etc).

The end result would be that the geek would create a table in any of the above mentioned RDMS's and my code would produce selected client interfacing.

For example Enter table deffinition. Check some buttons and click some buttons and out comes a zip file that has a web form .NET project to add/update/delete/select records from the given database(or specific tables). The developer can then take that code and with minor changes, (cosmetic security) and use it as there own.

The beauty would be that if the developer wants to define table for mysql they can change to to MSSQL with click button, and whatever code produced before will remain unbroken.

I realize this is 'code review' and I have no code. But any good durable code goes through this design phase.

Any thoughts on the concept?

I appreciate the thoughts thus far. I agree with much of what is said. The deliverable after selecting option boxes and clicking buttons would not be 'finished product'. Largerly the developer will still be required to make the screen pretty. If a there is two tables tblOrders and tblOrderItems - the end result would be two 'forms' for each. This is not ideal for the 'user' but helpful for the developer. Each part of the deliverable will require some developer/DBA 'tweaking'.

  • 6
    ORMs, persistence managers, various sorts of "frameworks" already do this. More or less badly. It's very hard to get right, given the slight semantic differences between the various DB engines and their (not slight at all) differences in how they "like" their schemas and queries designed.
    – Mat
    Commented Jan 5, 2015 at 16:26
  • 4
    These kind of tools may sound like music to some developers. "Just click, transparent, transferable, platform independent, etc." ...but in fact it's crap. Tools like these just make developers think that they do not need any knowledge of the database they are using. This again leads to faulty and bad performing applications.
    – o0x258
    Commented Jan 5, 2015 at 17:11
  • 2
    Perhaps you can find more enthusiastic supporters in stackoverflow.com -- I guess most DBAs would say the same thing as I just did.
    – o0x258
    Commented Jan 5, 2015 at 17:13
  • 2
    Sounds like a bad idea, because only DBA's and developers understand the different between quality code and "some generated code". If it was so simple, there would be no DBA's and developers at this day. Truth is, there's more and more, to cover more and more bugs. How are you going to deal with bugs, let the end-user fix them ? What you may be able to do, is deliver something with a low quality end result.
    – tvCa
    Commented Jan 5, 2015 at 17:20
  • 1
    en.m.wikipedia.org/wiki/Object-relational_impedance_mismatch is where you should start reading about why not to try this. If it doesn't keep you busy, then contemplate how you'd handle the discrepancies between release families of just one rdbms, and then think about what subset of which SQL standard you'll support, since you can't be fully cross-platform unless every target platform has a way to do everything you want to try to support through your abstraction interface. Commented Jan 6, 2015 at 1:36

3 Answers 3


Code generators are great! Code generators are evil!

10-15 years ago, I would have said that having a code generator for quickly creating the boiler plate code for database driven applications would have been a great gift to mankind.

5-10 years ago, I would have said code generator sucks, they generate too much duplicate code and that having a data-driven user interface (where the fields on the screen, validation, etc is driven by meta-data in a database instead of coding the screens one by one) would have been a great gift to mankind that supplanted the code generators.

Today I would say - write each screen individually. Use existing framework that wire fields and model objects and possibly ORM when doing simple CRUD. But do design each screen to the exact purpose of the screen. Application screens that mirror a RDMS table too much is only good for managing lookup tables. Don't annoy the user with geeky interface that are designed against a computer storage model (RDMS)... make a screen that has only what they need. That may mean that it will save to multiple tables, etc. Who cares. The user isn't a database.

So my thought? Don't waste your time making a code generator.


Erwin has a macro language for writing stored procedures that can be compiled against Oracle or SQL Server. You write, IMHO ugly code, with variables that will get translated to something understandable by a particular database engine, then Erwin will create a translated version for that database engine. I have not worked with Erwin in years, so I am not sure that it still has the feature. IMHO, you develop databases and applications for a specific database engine, so that you can use the best features of that database to get the best database application.


For simple reference data maintenance this may have some use. The market for this is crowded. Most every IDE will have a data grid with a connection behind it which will allow this sort of thing already.

Any non-trivial business operation is likely to touch more than one table. To implement these is so much more than a string of CRUD SPs wrapped in a database transaction. Capturing and generating those cross-dependencies will be difficult.

As a project it may provide a lot of personal satisfaction. As a commercial enterprise I can't see it gaining traction, however. Sorry.

Not the answer you're looking for? Browse other questions tagged or ask your own question.