The question is why use the database to generate unique id's? There is a
pattern at www.theserverside.com that describes a simple, reliable, scalable
technique to generate a reasonable GUID. While most applications will use
databases as their only persistent storage, what is the benefit of
introducing additional coupling by utilizing the database for unique id's?
Scott
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 11, 2001 11:57 AM
To: '[EMAIL PROTECTED] '
Subject: RE: [JBoss-dev] Object Unique Id Generator
You are right that a unique identifier is not a database specific concept,
and that unique id bean is a good tool to have in your toolbox. Sometimes,
like when using LDAP or message queues you're going to need it.
However if I am storing my data in an RDBMS (like most EJB developers will
be) why not use the RDBMS' built in facilities for generating unique keys.
If the data is persisted into the RDBMS it must be there for the application
to run (persist new data or load old data). RDBMS products have been making
unique ids efficiently since the client server days.
I just don't buy this super size distributed enterprise needs GUIDs from a
separate session bean thing for every application using EJBs. A lot of EJB
applications will benefit from simple design (IMHO database generated keys
fit this bill, but it's religion) and don't need all this stuff.
Besides, if you decide to change things, then change the unique ID
generation. It's not as if you're just going to take an application that
works with Oracle and plug it into a LDAP server or a message store. Sorry,
I've never seen it. In any application that has been optimized in terms of
data access there is always some database specific tuning involved and this
likely won't work on the next one.
In terms of coupling, I think once you deploy the application most users are
coupled to the database. The developers might say, "Ha this baby is 100%
portable it'll run anywhere," but the DBAs who only know SQL Server or
ORACLE and aren't in a hurry to migrate 200 GB of data probably know the
score. Most companies don't move internal apps around without good reason,
nor do they do it frequently.
There is a small set of applications that will benefit from using a seperate
bean for the enterprise super scalable thing, and a larger set of
applications using databases on the low end which don't have efficient
mechansisms for generating unique ids who will also benefit, but most people
building real IS/IT applications IMHO should be using database generated
unique ids where it makes sense, e.g. when storing the data into an RDBMS.
Cheers
Jay
-----Original Message-----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 4/11/01 11:37 AM
Subject: RE: [JBoss-dev] Object Unique Id Generator
The unique id is not a db concept. The application should have the
flexibility to use multiple persistent stores such as directory servers,
message queues, files, etc. The id should not be dependent on any one
persistent store for generating id's because it binds the other
persistent
storages to that particular persistent store, the application itself
should
provide id's to reduce coupling between the components of the system.
What
is the benefit of having the id generation inside the database? At best,
the
database can only guarantee database scope uniqueness.
Scott
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
