Re: NextNumbers Tables

From: Alan Gutierrez <ajglist_at_izzy.net>
Date: Wed, 12 Feb 2003 00:09:33 GMT
Message-ID: <Pine.WNT.4.53.0302111803350.1376_at_CX1198465-B>


stu wrote:
> "Alan Gutierrez" <ajglist_at_izzy.net> wrote in message
> news:Es82a.25941$tQ1.1811334_at_news2.east.cox.net...
>
>>stu wrote:

>> > To be honest I could not give a monkeys if all my tables are fully
>> > normalised :-). If they do their job and it makes developing easier (=
>> > faster = less cost) the customer is happy and that is my job. So from
>> > this respect would it be better to use surrogate keys as primary keys?

>>Don't be so lazy. This is a design decision. Either you develop an
>> understanding of normalization, and make educated decisions about
>> when to denormalize, or hire someone to design your database for you.

> I actually dont agree with what I posted! It is the view my boss wants me
> to have. His views are starting to change how I think about DB projects.

>> > No offence intended. It has just been drummed into me that it is better
>> > to get something working sooner rather than working on all the theory,
>> > and I have seen this in practice: ppl who sit + wonder about all the
>> > theory tend to take far longer to deliver projects if at all. I like
>> > looking at this NG to see if I can take anything to help me be a better
>> > designer but I like to KISS (Keep It Simple Stupid)!

>>You are not listening Stu. Your attitude needs some adjusting. You don't
>> seem to be too comfortable with critical thinking. I say this
>> because for two reasons. First, you are hostile towards theory and
>> design. Second, when presented with new information you continue to
>> ask the same question.

> Im not hostile towards design. Look at some of my other posts. "ppl who
> sit + wonder about all the theory tend to take far longer to deliver" was
> refering to myself when i started working after uni! But im being forced to
> make design choices faster than i think i should make them.

> Sorry if im persistant, I just get frustrated because my mork mates all
> think like my previous post. And I want really good reasons to stop them
> from making crap design choices.

[snip]

>>To experienced database developers, to question the whether a relational
>> database should be normalized is like questioning whether a boat
>> should be water-tight. If a relational database is not normalized,
>> you do not have a relational database. Use a spreadsheet.

>>As far as your admonisment to be stupid and simple I will now offer the
>> obligitory Einstien quote "Everything should be as simple as
>> possible, but no simpler." The point being that the complexity of
>> the problem will express itself in one form or another. If your
>> database schema is simplistic, your queries are going to be
>> extreamely complex.

> Point sinking in!

[snip]

> Really did not mean to cause offence Alan, and any others.

No offense taken. I understand the pressure you are facing. It is hard

    to find a balance between design and implementation. It's good that     your firm is pushing you to get things done, as long as they forgive     the mistakes you make in the rush. Don't get bogged down in some     petty argument about theory versus the real world. Know that it is     more nuanced then that. Do what your firm requests. Continue to     build your understanding.

A while ago, I was asking this group about natural keys in a thread

    called 'help finding natural keys'.

    http://groups.google.com/groups?th=77167e54ea12e34f

Using a natural key as a primary key has real world benifit. It prevents

    duplication of data. Duplicates can have consiquences if you are     billing customers, or scheduling chest x-rays, or assigning landing     strips at Heathrow. If your customers are billed monthly, you can     use the month as part of the natural key, and you will be ceritan     that only one bill exists for that month. The chest x-ray could have     the time rounded to the quarter hour and location as part of its     natural key.

If you are going to use a surrogate key, give thought to how your

    application will prevent duplicates. You will have to write     procedural code, or add extra unique indicies. It will no longer be     a natural fact of your database design.

There are times when a natural key cannot be found, or cannot be known

    by the application. People are tough. Since they stubbornly refuse     to surrender their genetic material when they book a car rental,     you'll probably have to make up a customer identifier. But even     then, there are better ways to generate the customer id than just     selecting max + 1.

Don't dismiss normalization, either. Read a good book on db design. A

    normalized database is easy to work with. It is well worth the     investment in time to understand the relational model. There are a     lot of people in the business world that take these principles     seriously and for good reason ($).

Alan Gutierrez - ajglist_at_izzy.net Received on Wed Feb 12 2003 - 01:09:33 CET

Original text of this message