Having been on the receiving end of consultant\vendor created apps that are built using techniques very similar to this, it is definitely not an approach that should be followed for anything other than small, quick and dirty, one off apps that won't be around for very long.
Dear Mr. Dundas: It appears that you are dismissing RAP based upon prior experiences with other products or concepts, and that you presume that because past efforts at higher levels of automation have not met your expectations, all future efforts are doomed to failure. I suggest that eventually someone will succeed.
Trying to transfer the whole RAD\Agile philosophy into the database design and implementation world is at best just lazy, at worst a huge waste of time and money as the project ends up being reworked from the ground up.
I am not an advocate of Agile philosophy. I am an advocate of generating mundane code that otherwise would almost certainly be poorly written and maintained by hand, and of pre-designing things that most people would design poorly given the chance (like auditing for example). Eliminating useless handwork does not constitute an advocacy of Agile methodology, any more than advocating the use of any other code-generating technology (such as compilers vs. assemblers) does.
With regards to your second remark about date fields and keeping all data in the "current" table, ...
RAP does not keep "all data" in the "current table". My article discussing this hasn't even appeared yet. RAP keeps only current data in the "current" table, allowing the application to properly delete obsolete records (and thereby respect referential integrity rules). All other auditing designs I have seen are considerably less systematic and rigorous, requiring the pollution of current data with former data in the same table. The RAP auditing design is discussed fully in the upcoming Part 3 of this article series.
I, also, have worked in a place where all data was kept in the "current" table and no rows were updated, other than to expire or logically delete them .... and while the SQL was complex, it was by no means a performance disaster
I am confused here by your use of my RAP term ("current table") to describe an application that is completely opposite to what RAP does. In RAP, the "current table" stores only current data and such data is indeed both updated and deleted.
I am glad that you were able to manage this design you describe and get good performance with it, but good performance and good design are not the norms that I have observed with such projects. Since your project never truly deleted records, presumably you could not then have the database assist you in maintaining referential integrity. And you yourself say the SQL was complex. Well the RAP code for accessing both current and archived data is both fast and simple (this is described fully in the upcoming Part 4 and Part 5 articles). In RAP, the SQL author is absolved of knowing whether data is current or archived, yet nonetheless his code can access both types of data with no more effort than an ordinary query would require to simply access current data.
Obviously it is possible to create a system where the database server must look through tons of obsolete data in order to find current data, and where the queries to access current data must be always written so as to eliminate the deleted data from the results, but why would you want do to this?
Now, every single query has to run against both the current and historical databases because the business needs to access data that was not considered "current" by the developers.
RAP does not have this problem; it runs against one or the other and it knows ahead of time which one to hit. The mechanism is described thoroughly in upcoming article series parts 4 and 5..
No one has ever been able to convince me that any of these code-generating\database-generating solutions is solid enough for serious use.
I cannot speak for your experience or the quality of what other vendors. I can say only that I have never seen anyone or any product solve the problems that RAP does in the way that RAP solves them. Never, ever, anywhere. Please take a look and see if it at least warrants some consideration.
I am taking a fundamentally different approach here than the people you've dealt with in the past. First of all I'm not forcing it on you, so you can feel free to ignore it. I deliver it in source form so if you don't like the way it does something you can change it. But most of all, it is being presented to the development community (via this article series) for everyone to look at it, play with it, and decide whether it at least contains some components or ideas worth using.
You are of course free to bet against the further future systemization and automation of the code generation process, and I am free to bet against you. Certainly RAP might not survive the test of popularity, and perhaps even my methods will not be the choice of the future, but in my opinion somebody is going to automate code generation to a far higher level of abstraction than what we are doing today. RAP is just my entry into the game.