richardd (10/13/2010)
It is entirely possible that an application would want to have consistent views of essentially all its tables that exclude things like status fields. So if I have an app where I need an entire set of views that correspond to essentially all the tables, I'd have to distinguish their names somehow. Better to do it consistently than inconsistently.
Beyond this there is a practical example that RAP actually uses (this is explained two or three articles down the road BTW). For every single primary key, foreign key, and unique constraint or index in each table, RAP generates a set of user-functions and a corresponding set of stored procedures that allow you to look up records in the table according to the fields of that key or index. The user functions are intended for use in any hand-written queries you may want to write (primarily for reports), whereas the stored procedures are intended for use by the application's data layer.
The user function and the corresponding stored procedure are identical except that one is a user function and the other is a stored procedure. So there's a choice here: invent some algorithm for inconsistently modifying the generated names of otherwise identical objects, or simply have a consistent naming convention for distinguishing them. RAP is all about consistency, so it uses the latter.
Examples of function / procedure pairs that RAP generates: For the table "TBadmUser" in the canned "ExampleCRM" demo that comes with RAP, RAP generates these two routines for looking up records via the primary key:
UFTBadmUser#PK (user function)
SPTBadmUser#PK (stored procedure)
Why does RAP generate these routines, you might ask? Well the main reason is that RAP fully audits everything, and it gives you everything you need to retreive all data, both past and present. Unlike code you might write yourself, these routines let you choose (by passing either a date or a null) whether you are going to be retrieving current vs. archived data. All this will be covered later in the series.