 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | Subject: sequence-block pattern | Subject: sequence-block pattern 2004-06-18 - By Koala
Back
Navjot Singh wrote:
>> This patters has several drawbacks, for example the real primary key
>> should be defined as UNIQUE and others stuff reported in EJBDesign
>> Pattern book.
>
> Primary key IS UNIQUE. What's the drawback here?
Suppose I have two entities Student and courses with the following
attributes:
Student: Courses:
-- ---- --- -- ---- --
name name
surname date
address
now (name, surname) could be a primary key for student and (name) could
be a primary key for courses. Suppose I have 10 elements in Student
and the size of index (for primary key) is 100 Kb.
It is clear that if I organize my tables in a different way, using
sequence block patters I could have:
Student: Courses:
-- ---- --- -- ---- --
id id
name name
surname date
address
where id is "effective" primary key for both the table and, to avoid to
have duplicate "real" primary key, I have to define (name, surname) on
Student has
UNIQUE (the same must be done for name in Couses).
Using this approach the size of index for primary key will be less than
100 Kb, since my primary key is a simple integer. This should improve
insert/search/update commands (I hope).
The question is:
is this approach appliable to all the entities of whatever database schema?
I am working on a project where this type of technique has been used and
I would like to know if it is a good choice.
>
>> Now I have a design question. If I have a DB schema with a set of table,
>> is it a good choice use a long id as primary key for all the tables?
>> When it could be necessary use long ids as primary keys? In which cases
>> I should avoid this?
>
>
> Wrong way to look at PKs. usually people keep one of smallest CANDIDATE
> Keys as primary key. Many people dont worry much about them and just
> keep auto_increment / sequence column as PK.
>
Yes. But do you think this is a good choice. Are there cases in which it
is better not define a "effective" primary key (probably you call it
CANDIDATE)
but use the "real" primary key?
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
