General J2EE: Limitations of Composite Keys in Table Design

  1. Limitations of Composite Keys in Table Design (1 messages)

    Hi all,
    > Can I get a Paper/Document on 'Limitations of Composite keys in Table designing'
    > Designers now a days says to aviod Composite keys as much as possible.Instead of Using Composite keys use a Sequnce No as PK and validate accordingly whereever it is required. Is it true? If yes can I get details regarding this.
    > Pls let me know in general when we need to go for Composite Keys and when to Single PK(Seq No).
    > Regards
    > B S Reddy

    Hi all,
      Iam waiting for the Reply
  2. I don't know of any papers on the subject, but I can give you a summary of my opinion.

    Traditional Data Modeling techniques often state that all relational data should be "real" values and that dummy primary key fields are a bad practice. If you follow this philosophy, you are pretty much forced to use composite keys.

    In practice, you can get much better performance and much simpler development if you define a meaningless numeric id field as the primary key for all of your tables. I use 64bit integers as the primary key field for everything, unless someone else insists otherwise. This consistency makes it much easier to define a mapping between my object model and my relational data.

    The only exception I make to this rule is pure join tables that are nothing more than foreign key references to other tables.