timothyawiseman (10/6/2010)
I think it makes sense to decide, if not table by table, then certainly database by database whether you want to use artificial keys. I find the idea of standardized audit fields even worse since they do not make sense for all tables, and unused fields tend to create confusion and waste.As to the comparison with the auto industry, I find it flawed. There the goal is precisely to mass produce large numbers of nearly identical products with interchangeable parts. It makes tremendous sense to standarize virtually everything in that and keep producing them. But no two software projects are absolutely identical (if they were, you would just copy the first one and be done with it).
Another thing to point out is that most assembly line workers are not the same as craftsmen. They just repeat the same thing over and over without trying to optimize for absolute performance. Software creation is much closer to that situation, then to assembly line workers repeating the same motions over and over.
Many good points here Timothy and let me respond to them. First with regards to artificial keys ... the whole point with RAP is to standardize the code generation and the ORM. I think it should be self-evident that one fantastic way to standardize and simplify an app is to have all the keys look exactly the same.
It would be way beyond the scope of this article and this blog for me to discuss all the benefits of using artificial keys, but let me focus on just one: you simply cannot audit a table that doesn't have one. Without an artificial key, there is no field in the table that guarantees continuity from one version of a row to the next (since business keys can always change). So artificial keys are critical to auditing.
Most people have never seen a 100% auditing application and so they can't imagine why you'd want to put status fields on every table. Well ... RAP produces 100% auditing apps. What this means is that you can actually log into your application "as of" a given date, and the app will open up with all of your data displayed as of that date. Screens, web pages, reports, everything. Even a web service, if that's what you're running. And that's just one advantage of having status fields in all tables. It's in the demo .. give it a try.
With regards to the auto analogy. Yes the analogy is flawed, because we are one level of abstraction higher here. With an auto assembly line the objective is to make a zillion of exactly the same thing. With RAP the objective is to make a zillion things whose underlying "plumbing" is built exactly the same way. A much better analogy would be the analogy to compilers, which use the same parameter-passing and code-generation techniques everywhere, but tailor them to whatever code you're writing.
But the automobile analogy is sexier.