in reply to OT: benefits of database normalization

I'm afraid I don't understand your schema. What is a "type"? Is it always just 1 or 2, with 2 meaning that it's an alias and that the data should be interpreted as a fact_id? Or are there other types? If there are other types, how are they represented in design #2?

Also, btw, both "name" and "type" are SQL reserved words and should not be used as column names unless they are quoted.

  • Comment on Re: OT: benefits of database normalization

Replies are listed 'Best First'.
Re^2: OT: benefits of database normalization
by astroboy (Chaplain) on Oct 03, 2004 at 08:53 UTC
    Really? I looked at the ANSI SQL-92, SQL-99 and SQL-2003 reserved words lists, and "name" and "type" weren't listed in any of them
      Technically, you are correct, the standard gives two lists of key words, reserved and non-reserved. It was wrong of me to say these are in the reserved list, the standard defines "NAME" and "TYPE" as non-reserved key words, not as reserved key words. However, C.J. Date, one of the authors of the standard, has this to say about non-resrved key words: "The rule by which it is determinded within the standard that one keyword needs to be reserved while another need not is not clear to this writer. In practice it is probably wise to treat all key words as reserved." A Guide to the SQL Standard, C.J. Date, p. 32.

      So I apologize for over-stating that these are reserved, but stand by my advice to avoid them as identifiers unless delimited.

Re^2: OT: benefits of database normalization
by revdiablo (Prior) on Oct 03, 2004 at 02:19 UTC
    I'm afraid I don't understand your schema . . . are there other types? If there are other types, how are they represented in design #2?

    There are only two "types". There are facts, and aliases. I don't really think of them as types, though. I think of them as completely different things. This is the crux of the difference between the two designs.

    2 meaning that it's an alias and that the data should be interpreted as a fact_id

    Yes, this is how Design 1 was intended to work.

    Also, btw, both "name" and "type" are SQL reserved words and should not be used as column names unless they are quoted.

    True. They were really just for the sake of the example.

Re^2: OT: benefits of database normalization
by pg (Canon) on Oct 03, 2004 at 02:19 UTC
    "Also, btw, both "name" and "type" are SQL reserved words and should not be used as column names unless they are quoted."

    Not true, at least not true to all database implementation. I just tried this in Oracle, and it worked with no problem:

    create table temp(type number(1), name number(1))
      The fact that Oracle lets you get away with using those doesn't mean that it is a good idea to use them anymore than the fact that MSIE lets you get away with sloppy HTML means that you should write sloppy HTML. If there's any chance that the schema will be ported to another RDBMS in the future (and the OP is asking questions about the long range), then it is better to avoid ISO/ANSI SQL reserved words. Another reason to avoid them is if the schema will be used with parsing, cataloging, or validating software which may or may not recognize them.