> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 26 March 2002 16:12
> To: [EMAIL PROTECTED]
> Subject: RE: (ROSE) Transforming Object Model to Data Model (Oracle)
>
>
>
>
> If you add unique indexes to all of the tables to replace the
> object id
> primary key, you've essentially implemented the same business
> rules as if
> you had not added object id and used the describing attributes as the
> primary key.
Indeed.
> Most people don't add the unique indexes to enforce the
> business rules.
Indeed, again.
> As such, the data gets corrupted. Why use
> object ID and
> unique indexes?
For the very simple reason that it makes developing general-purpose
persistence mechanisms much, much easier.
The mechanism may take the form of code generation for every table in the
schema or it may be a set of classes/components that handle database access
given some parameters. In either case, when you provide navigation through
surrogate keys (all of which, presumably, would have the same name and type)
becomes straightforward. When you try to do the same with the natural keys,
you have to introduce a whole new level of complexity.
Don't get me wrong -- I'm not arguing against using natural keys. If you
have a thrid party tool like PowerTier that will already let you use the
natural keys, you've already solved the problem. It's when you have to
develop your own persistence layer for whatever reason that
surrogate/synthetic keys really make a difference.
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/21/2002 07:31 AM
>
> Please respond to
>
> "Angay, Huseyin"
>
>
>
>
>
>
>
>
> > -----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
> **************************************************************
> ***********
>
>
>
> **************************************************************
> **********
> * 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
*************************************************************************
