• (cs) in reply to emptyset
    emptyset:

    Anonymous:
    I'm almost tempted to do a proof of concept implementation for some simple DB like Sqlite where it would be quite easy to hook it in.... If only I had time :)

    <FONT face="Courier New" size=2>vidar,</FONT>

    <FONT face="Courier New" size=2>bring me the gentle force of magma.  take it to the accumulator and continuously destroy the toppings.  please produce a notarized stamp in the likeness of the virgin mary; my heart condition requires it.  walk my minature schnauzer in the darkness of the full moon.  cook me the soup of a thousand meals and provide a large stack of those addictive crackers you crumble up and throw in.  make the signal propagate through the air and land in the basement of a man by the name of charlie: he's got red hair and a big cigar.  participate in the octagon and win the prize.  watch out for snakes.  feed the giant panda before it destroys the fig tree.  ordain yourself and marry this lamp to my third cousin.</FONT>

    <FONT face="Courier New" size=2>sincerely,</FONT>

    <FONT face="Courier New" size=2>emptyset</FONT>

    The one gem in there is "watch out for snakes."  A six foot rattler bit one of my BTs this spring when we were camping and killed him.

  • (cs) in reply to RevMike
    RevMike:
    ammoQ:
    brazzy:
    ammoQ:
    If you build a system especially for one company, you can depend on their business rules. They say "emplyee numbers are unique and never change" and you use it a your primary key. No problem.

    Until they merge with another company and say "we need to change the employee numbers so that the two companies' employee number systems don't collide". I rather doubt they'll be happy with the answer "That's impossible. You said the numbers would never change and I based my DB design on that!"

    The correct answer in that case: "It's possible, but it will cost a lot. The requirements specification said the numbers would never change and I based my DB design on that!"



    Don't forget that for fundamental changes such as this, lots of things need to change and the data model is only one of them.  To use your employee number change as an example:  Even if the data model is quick and easy to change, it isn't hard to imagine that easily 50% of your transaction screens and reports will need to be modified.  Unless someone did a truly amazing design job, the application changes are likely going to dwarf the data model changes regardless.

    Anytime you modify a key that is fundamental to your system, it is going to be expensive.  Should adding a few hundred thousand dollars on a several million dollar project that may or may not happen at indeterminate time in the future drive your design decisions now?  This potential future expense has to be balanced against needing to perform additional joins for virtually every query right now, as well as maintain additional indexes and constraints for a large percentage of your tables.


    I aggree, a one-time change - like that caused by a merger that may or may not happen - is not a sufficient reason for using artificial keys. Our main motivation for regularly using artificial keys are not the sporadical or hypothetical changes on a given project, but the inevitable changes when doing several similar projects; extra difficulties arise from the circumstance that the ERP system our program is interfacing dictates the structure of many natural keys; there's a lot of standard ERP systems out there plus some indiviually made systems. To make some of the more sophisticated parts of the code reusable between the projects, they must not depend on the structure of the natural keys. Yes, Screens and reports probably need adjustments, but that's just a minor part of the game.
  • Somebody (unregistered)

    The tYearNumber might make sense if this application were designed to be in use really long, while one expects holes to form in this table in the future

    In that case, the one billionth entry in the table might easily exceed 2^64, or whatever is the database's limit for integers ;-)

  • vbNullString (unregistered)

    I shit in my pants by looking at this.

  • byte_lancer (unregistered)

    WOW
    I'd like to see the ER diagram behind it and also have a look at the log file sizes of the live database.
    Wonder what would happen if a normal form validator ran through the DDL script ?

Leave a comment on “A Truly ID-iotic Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article