Can I get away with not using OID's? As I want the data model to remain completely independant from the persistence framework. If so what are the implications if any.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are no implications. It's merely a design issue.
The idea behind using oids and/or guids as keys is to provide a mechanism for key abstraction.
For instance if a table needs 5 columns for a primary key, then those 5 columns must be duplicated in all other tables that will reference the key.
An oid or guid, allows you to use a single column for referencing a row in a table, and to only use that one column in all the other tables.
Also, oids/guids provide a consistent mechanism for table referencing. If you want to access data in a table you know you need to use an OID, regardless of the target tables structure.
Finally, OIDs were provided since not all databases have support for GUIDs, and they provide a much shorter column width than a guid (12 character vs 30).
Note: The use of OIDs typically means that you should mark your traditional primary key (ie the 5 columns) as "find" columns, so you can still easily locate data.
- Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can I get away with not using OID's? As I want the data model to remain completely independant from the persistence framework. If so what are the implications if any.
It's not a problem at all. Just make sure your existing key properties have the attribute key="primary" in the mapping
If you have multiple fields in the key, make sure that each property that participates in the key is marked.
I'll put an FAQ on the web site to explain it in more detail.
- Richard.
Hello,
I have the same question that womber, what are the full implications for not using oid's in database schema.
Thanks for the answer.
There are no implications. It's merely a design issue.
The idea behind using oids and/or guids as keys is to provide a mechanism for key abstraction.
For instance if a table needs 5 columns for a primary key, then those 5 columns must be duplicated in all other tables that will reference the key.
An oid or guid, allows you to use a single column for referencing a row in a table, and to only use that one column in all the other tables.
Also, oids/guids provide a consistent mechanism for table referencing. If you want to access data in a table you know you need to use an OID, regardless of the target tables structure.
Finally, OIDs were provided since not all databases have support for GUIDs, and they provide a much shorter column width than a guid (12 character vs 30).
Note: The use of OIDs typically means that you should mark your traditional primary key (ie the 5 columns) as "find" columns, so you can still easily locate data.
- Richard.