Database design what are your thoughts 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'.
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.