> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 20 March 2002 18:36
> To: Angay, Huseyin
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: (ROSE) Transforming Object Model to Data Model (Oracle)
>
>
>
> I'm not against surrogate keys. All of my data models have
> them. They are
> necessary when there are no attributes or combination of attributes to
> uniquely identify a entity occurrence. I also have
> implemented surrogate
> keys as a performance tuning measure on large compound
> primary keys. The
> problems come in when you make all the primary keys non-intelligent
> (surrogate).
Things can get very black and white when you look at them only from the
database side. When you start considering how the techniques affect other
parts of the development work, the answer is not necessarily so clear.
> This essentially removes the data integrity of
> the database.
> I've seen many cases where the data in the database was
> corrupted while the
> referential integrity of the tables was still fine. This
> situation happens
> most often when the referential integrity of the database is
> turned off, or
> the tables all have non-identifying relationships (surrogate
> keys).
The problem here goes beyond surrogate keys, in fact. If you rely solely on
surrogate keys for database integrity, you are certainly not going to get
integrity of information. Whether you use them as physical keys or not, you
still need to set your uniqueness constraints for the natural keys. When the
DBAs have been negligent in this task (We have ~a~ key, haven't we? So why
bother?), I have seen integrity problems that could not be detected.
The other problem comes when your code relies on the surrogate keys beyond
the task of navigation. I have, for instance, seen configuration files that
contain entries that refer to a surrogate key. That's just lazy coding.
> This
> allows for application logic errors to be persisted with no
> objection from
> the database.
It will, if you leave your natural keys as simple data fields, without
telling your dbms about their integrity constraints.
> I've yet to encounter a database built totally
> on surrogate
> keys that does not have data integrity issues. That's not to say they
> don't exist, It's just that I haven't seen them and as a
> result, cannot
> recommend it as good design.
>
My experience has been the opposite.
The surrogate keys make code generation a good order of magnitude easier.
Whenever I worked in projects where the data access layer was hand-coded
because the DBAs would not allow blanket surrogate keys, which made writing
a code generator or a general-purpose data access components a costly
proposal, we had information integrity problems. These weren't database
integrity problems, so the DBAs got to sleep easy. Instead, people writing
the application code had trouble every time any changes happened to the
schema. I also saw a lot of lazy application coding that relied only on the
database to ensure integrity, when we used the natural keys as physical
keys, too (The DB does the job, so why bother?). These are typical problems
with the database becoming the architecture.
On the other hand, in projects where most of that work was left to code
generators, there was enough effort spared to allow everyone to pay more
attention to data integrity.
Yes, you can avoid these problems by having your database schema decided
from day one and by never touching it again. Is that how we should develop
systems, though?
Regards,
H�seyin Angay
Karabash Ltd.
www.karabash.co.uk
> Regards,
> Walter Howard
> Data Analyst
>
>
> `Give your evidence,' said the King; `and don't be nervous,
> or I'll have
> you executed on the spot.' - Alice in Wonderland
>
>
>
>
> "Angay, Huseyin"
>
> <Huseyin.Angay@egg. To:
> [EMAIL PROTECTED]
> com> cc:
>
> Sent by: Subject:
> RE: (ROSE) Transforming Object Model to Data Model (Oracle)
> owner-rose_forum@Ra
>
> tional.com
>
>
>
>
>
> 03/20/2002 09:58 AM
>
> Please respond to
>
> "Angay, Huseyin"
>
>
>
>
>
>
>
>
>
>
> Is there a particular reason for not liking the approach, Walter?
> Most of the techniques described in the paper are pretty much the
> established methods for dealing with persistence. What do the
> data folks
> have against it?
>
> Regards,
> H�seyin Angay
> Karabash Ltd.
> www.karabash.co.uk
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> > Sent: 18 March 2002 15:24
> > To: [EMAIL PROTECTED]
> > Subject: Re: (ROSE) Transforming Object Model to Data
> Model (Oracle)
> >
> >
> >
> > BTW, most data folks don't like Scott's approach.
> >
> > Regards,
> > Walter Howard
> > Data Analyst
> > 972-465-4297
> >
> > `Give your evidence,' said the King; `and don't be nervous,
> or I'll have
> > you executed on the spot.' - Alice in Wonderland
> >
> >
> >
> >
> > PaulOldfield1@compu
> >
> > serve.com To:
> >
> > Sent by: cc:
> "Barrett, Kathy
> > (PLC, IT, Lambert Technical Services)"
> > owner-rose_forum@ra
> > <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'"
> > tional.com
> <[EMAIL PROTECTED]>
> >
> > Subject:
> Re: (ROSE)
> > Transforming Object Model to Data Model (Oracle)
> >
> >
> > 03/15/2002 04:00 AM
> >
> > Please respond to
> >
> > PaulOldfield1
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (responding to Kathy Barrett)
> >
> > > I am trying to understand how relationships are transformed
> > > from the Object Model to the Data Model (using an Oracle
> > > database). My experience is in the relational world, and I'm
> > > new to Object, so please excuse my use of terminology.
> >
> > Addendum - there's a good document from Scott Ambler on the
> > topic at
> >
> > http://www.AmbySoft.com/mappingObjects.pdf
> >
> > If you're already up on one side (Relational in your case, most
> > readers are up on the Object model) this should be a good
> > place to ramp up your knowledge.
> >
> > HTH,
> >
> > Paul Oldfield
> >
> > any opinions expressed herein are not necessarily those of
> > Mentors of Cally
> >
> **************************************************************
> **********
> > * Rose Forum is a public venue for ideas and discussions.
> > * For technical support, visit http://www.rational.com/support
> > *
> > * Post or Reply to: [EMAIL PROTECTED]
> > * Subscription Requests: [EMAIL PROTECTED]
> > * Archive of messages:
> > * http://www.rational.com/support/usergroups/rose/rose_forum.jsp
> > * Other Requests: [EMAIL PROTECTED]
> > *
> > * To unsubscribe from the list, please send email
> > * To: [EMAIL PROTECTED]
> > * Subject: <BLANK>
> > * Body: unsubscribe rose_forum
> >
> **************************************************************
> ***********
> >
> >
> >
> >
> >
> **************************************************************
> **********
> > * Rose Forum is a public venue for ideas and discussions.
> > * For technical support, visit http://www.rational.com/support
> > *
> > * Post or Reply to: [EMAIL PROTECTED]
> > * Subscription Requests: [EMAIL PROTECTED]
> > * Archive of messages:
> > * http://www.rational.com/support/usergroups/rose/rose_forum.jsp
> > * Other Requests: [EMAIL PROTECTED]
> > *
> > * To unsubscribe from the list, please send email
> > * To: [EMAIL PROTECTED]
> > * Subject: <BLANK>
> > * Body: unsubscribe rose_forum
> >
> **************************************************************
> ***********
>
>
> This private and confidential e-mail has been sent to you by Egg.
> The Egg group of companies comprises Prudential Banking plc
> (registered no. 2999842), Egg Financial Products Ltd (registered
> no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
> carries out investment business on behalf of Egg and is regulated
> by the Financial Services Authority. All members of the Egg group
> are registered in England and Wales. Registered offices: 142
> Holborn Bars, London EC1N 2NH
>
> If you are not the intended recipient of this e-mail and have
> received it in error, please notify the sender by replying with
> 'received in error' as the subject and then delete it from your
> mailbox.
>
> **************************************************************
> **********
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Post or Reply to: [EMAIL PROTECTED]
> * Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> * http://www.rational.com/support/usergroups/rose/rose_forum.jsp
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> * To: [EMAIL PROTECTED]
> * Subject: <BLANK>
> * Body: unsubscribe rose_forum
> **************************************************************
> ***********
>
>
>
>
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Post or Reply to: [EMAIL PROTECTED]
* Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
* http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
* To: [EMAIL PROTECTED]
* Subject: <BLANK>
* Body: unsubscribe rose_forum
*************************************************************************
