On 8/17/06, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
I'm not trying to promote the creation of tables w/o PKs, but just FYI - I work with the Baan ERP application (you've probably never heard of it,
Heard of it, never seen it.
their largest customer) and they do not use PKs or any RI in the database - they use unique indexes with not null constraints, and they manage all the RI w/in the application. Not ideal, but I must admit they've done a pretty good job of implementing it this way - it's never caused us any problems in the 8yrs I've been working with it. I've heard that some of the other big ERPs (maybe even SAP - anyone know?) are designed similarly.
True it is not ideal.
The big difference between an app like this and a custom in house bag of columns is that it was modeled and designed.
SAP is similar. They do not use RI nor PK. They do have unique indexes with NOT NULL columns, so PK can be created if necessary. (Think replication)
While I don't care for some of the things SAP does, they do a good job of maintaining integrity within the app.
There are various reasons for doing this.
* migrated from another platform (VSAM) * run on several databases without regard to how the db enforces integrity.
can't easily view the relationships for reporting purposes when trying to use Crystal or some other 3rd party reporting tool.
No kidding.
SAP is lotsa fun.
The one thing that is done in SAP (and needs to go away) is pool/cluster tables.
The physical table has a few key columns and one LONG RAW column for the data, which is compressed (and unreadable except thru ABAP). There are several logical tables in a physical table.
When you are trying to do something directly from the database and run into that, you are done.
-- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist
