Brian: Let me illustrate the benefits of the RAP approach with a scenario. Let's say you and I both implement the same application and we have the same user running both apps side by side. At the end of some time, our user has entered 1 million records into a particular table but has also deleted 400,000 of them, so that there are only 600,000 "current" records in the table.
In the RAP application, when the user queries the table for current data, the server looks only in the "current" table, which contains only current records, so it has to search only through 600,000 records. In your application, the server has to look through 1 million records.
In your application, every programmer writing every query into this table must remember to check for the "D" flag, and the server has to perform this test on every record in every query. The RAP application author (and server) does not need to check any flags - he just writes the natural query with no consideration of any audit or status fields.
In the RAP application, I have stored every version of every record, including every version that was created by repeatedly updating the same record. This means that when querying historical data (as the RAP "ExampleCRM" app does when you log in using a date), the application can see a snapthot of all the data in the entire application as of any given date. For example if I want to see ALL of my data exactly as it was six months ago (including all screens, reports, etc.) all I do is specify a date of "six months ago" and it's as though I had logged into the app on that day. Nothing is ever lost. And since all these record versions are stored separately from the "current" data, there is no performance cost for storing them when looking up current data, no matter how many there are. In your app, the best you can ever do is see the latest version of each record, because that's the only version you've got; there is simply no way for you to reconstruct all your data as of a given past date.