Re: Linux Advocacy is completely Dead...... - Linux

This is a discussion on Re: Linux Advocacy is completely Dead...... - Linux ; In comp.os.linux.advocacy, DFS wrote on Sun, 16 Sep 2007 15:41:13 -0400 : > Kier wrote: >> On Sun, 16 Sep 2007 14:32:22 +0100, William Poaster wrote: >> >>> [H]omer wrote: >>> >>>> Verily I say unto thee, that William Poaster ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 63

Thread: Re: Linux Advocacy is completely Dead......

  1. Re: Linux Advocacy is completely Dead......

    In comp.os.linux.advocacy, DFS

    wrote
    on Sun, 16 Sep 2007 15:41:13 -0400
    :
    > Kier wrote:
    >> On Sun, 16 Sep 2007 14:32:22 +0100, William Poaster wrote:
    >>
    >>> [H]omer wrote:
    >>>
    >>>> Verily I say unto thee, that William Poaster spake thusly:
    >>>>
    >>>>> Doofy even buys a magazine about an OS he hates, how idiotic is
    >>>>> *that*?
    >>>>
    >>>> LOL!
    >>>>
    >>>> That'd be like me buying a copy of "RAD Developer Monthly" just to
    >>>> get the free crayons on the cover.

    >
    > What is it you do for a living, Dumb Willie? What software do you use at
    > work? Do you have any software skills at all?
    >
    > If you think RAD means crayons, etc, why don't you show me how well you can
    > build a user interface (whatever tool you want, as long as you do the work
    > yourself) around this db structure:
    >


    ObYuck: Yuck. Can't your database handle 'CONTACT' like
    normal DB systems? :-P Then again...I'd have to look;
    it might be a keyword.

    >
    > CREATE TABLE TL_CNTCT
    > (
    > CNTCT_ID NUMBER(8,0) NOT NULL ,


    Not unreasonable thus far. However, restricting it to
    8 digits looks a bit arbitrary. 2^31 = 2147483648 --
    10 digits. The identifier probably should be expanded to
    'CONTACT_ID' in a perfect world.

    > CNTCT_TYP VARCHAR(5) NOT NULL ,


    I don't like enumerated types represented as varchars.
    (In our database, we have a mix. Some of our
    enumerated/quasi-enumerateds are represented as numbers,
    with a lookup table for convenience. Others are multichar
    codes much like CNTCT_TYP. Not a lot I can do about it;
    we convert them when we can.)

    > DEPT VARCHAR(20) NOT NULL ,


    A quasi-enumerated type. This probably should be a
    foreign key. Is there a TL_DEPT table? There are also
    scoping issues -- where's the company for this department?

    > TITLE VARCHAR(30) NOT NULL ,


    Interesting notion. Are we supposed to assume 'The Duke Of
    Wellington' fits in here? Or is this restricted to 'Mr',
    'Mrs', 'Miss', 'Mz'?

    > LAST_NM VARCHAR(35) NOT NULL ,


    Standard surname stuff.

    > FIRST_NM VARCHAR(35) NOT NULL ,


    Standard firstname stuff. No middle initial?

    > ADDR1 VARCHAR(35) NOT NULL ,


    I suppose this is more generic than 'NUMBER/STREET/UNIT', but
    am wondering if 35 is enough. Then again...

    > ADDR2 VARCHAR(35) NULL ,


    Compromise, thy name is address field. Also, is the NULL a
    typo, or an indication that this field may in fact be null?
    I'm hoping the latter.

    > CITY VARCHAR(30) NOT NULL ,


    Another quasi-enumerated type, though so large there's
    probably no point in representing it as such.

    > STATECD VARCHAR(2) NOT NULL ,


    Extremely restrictive. Also, no provision for
    international provinces.

    > ZIP VARCHAR(9) NOT NULL ,


    Ditto.

    > EMAIL VARCHAR(50) NULL


    No phone numbers? Or is that separate?

    > );
    >
    > ALTER TABLE TL_CNTCT
    > ADD CONSTRAINT PK_TL_CNTCT PRIMARY KEY
    > ( CNTCT_ID );


    OK.

    >
    > CREATE UNIQUE INDEX UIDX_CONTACT ON TL_CNTCT
    > ( LAST_NM, FIRST_NM, ADDR1 );


    OK, I suppose. I'd key on ADDR2 but with a NULLable field
    in an index things get a little interesting. This doesn't
    look very reliable.

    >
    > -----------------------------------------------------------------------------
    > CREATE TABLE TL_CNTCT_PHONE


    Ah, phone numbers.

    > (
    > PH_ID NUMBER(8,0) NOT NULL ,


    A little odd. Of course there is the possbility that two
    or more contacts could share one phone number (if they
    happen to share a cubicle booth or do not have direct
    lines and thus have to all go though the company's main
    switchboard), so that's probably OK.

    > CNTCT_ID NUMBER(5,0) NOT NULL ,


    Inconsistent foreign key; should be NUMBER(8,0).

    > PH_TYP VARCHAR(10) NOT NULL ,


    Another enumerated type.

    > PH_NBR VARCHAR(25) NOT NULL ,


    I suppose this is tolerable, and does allow for
    extensions and international dialing codes if necessary.

    > );
    >
    > ALTER TABLE TL_CNTCT_PHONE
    > ADD CONSTRAINT PK_TL_CNTCT_PH PRIMARY KEY
    > ( PH_ID );
    >
    > CREATE UNIQUE INDEX UIDX_CNTCT_PH ON TL_CNTCT_PHONE
    > ( CNTCT_ID, PH_TYP );


    No index on PH_TYP and PH_NBR? With Caller-ID, one might
    want that.

    >
    > -----------------------------------------------------------------------------
    > CREATE TABLE TL_CNTCT_TITLE
    > (
    > TITLE VARCHAR(50) NOT NULL ,
    > TITLE_LDSC VARCHAR(50) NOT NULL


    This is ridiculous. The long description should not be
    the same size as the short description.

    > );
    >
    > ALTER TABLE TL_CNTCT_TITLE
    > ADD CONSTRAINT PK_TL_CNTCT_TITLE PRIMARY KEY
    > ( TITLE );
    >
    > CREATE UNIQUE INDEX UIDX_TITLE_LDSC ON TL_CNTCT_TITLE
    > ( TITLE_LDSC );


    OK, though I'm not thrilled.

    > -----------------------------------------------------------------------------
    > CREATE TABLE TL_CNTCT_CHAIN


    Not sure what this one's for.

    > (
    > CNTCT_ID NUMBER(5,0) NOT NULL ,


    Another inconsistent foreign key.

    > CHAIN_CODE VARCHAR(2) NOT NULL


    Not sure what this is, but this is probably a
    quasi-enumerated type again.

    > );
    >
    > ALTER TABLE TL_CNTCT_CHAIN
    > ADD CONSTRAINT PK_TL_CNTCT_CH PRIMARY KEY
    > ( CNTCT_ID, CHAIN_CODE );


    This table is all index, then. Good for storage.

    >
    > -----------------------------------------------------------------------------
    > CREATE TABLE TL_CNTCT_STATE


    This one needs to be extended to include country; state
    should be changed to province, or left as is.

    > (
    > CNTCT_ID NUMBER(5,0) NOT NULL ,


    Another inconsistent foreign key.

    > STATECD VARCHAR(20) NOT NULL


    This looks like a typo. Did you mean VARCHAR(2)?

    > );
    >
    > ALTER TABLE TL_CNTCT_STATE
    > ADD CONSTRAINT PK_TL_CNTCT_ST PRIMARY KEY
    > ( CNTCT_ID, STATECD );


    Another all index table.

    * * *

    There is a 'TEXT' type that PostgreSQL supports -- not sure
    how standard it is. Such might be useful for TITLE_LDSC.

    As already noted, this screams for internationalization.
    This is arguably most easily done by simply making the
    zipcode bigger (at least it's alphanumeric, which helps)
    and including a country three-letter code. (Most countries
    are two-letter but there's a few oddballs in there.)
    25-digit phone numbers look OK, though there's arguably
    a lot of quirks out there, depending on how well the
    local exchanges work once one has gotten through the
    international stuff.

    As an example, the UK Prime Minister's address is

    10 Downing Street,
    London,
    SW1A 2AA
    United Kingdom

    The phone number for his fax is +0442079250918, if I'm
    not mistaken; the +044 is an international prefix. In UK,
    one reaches his FAX by dialing 02079250918.

    (This is all from http://www.number-10.gov.uk/output/Page3.asp
    so don't worry too much about my spreading personal info
    here. :-) I don't know Mr. Brown personally, certainly!)

    The Canadian prime minster (Stepher Harper) has similar
    quirks (stands to reason, actually):

    Office of the Prime Minister
    80 Wellington Street
    Ottawa
    K1A 0A2
    Canada

    with 6139416900 or +0116139416900 as his fax number.

    (http://www.pm.gc.ca/eng/contact.asp?featureId=10)

    A list of international dialing codes is at

    http://www.kropla.com/dialcode.htm

    International domain names are going through a transition phase
    right now, as ICANN releases sections of its authority to regional or
    country systems. I frankly don't know what's going to happen, but
    for now

    http://www.iana.org/root-whois/index.html

    is probably as good a reference as any for such, from
    Ascension Island (.ac) to Zimbabwe (.zw).

    > -----------------------------------------------------------------------------
    >
    >
    > Talk's cheap, and you're all hot air chump, and you'll slink away
    > as fast as possible. So
    > did Rex Ballard, who called my work trivial. And Jabba Bailo.


    Not sure this is trivial, but it's definitely easy to
    spot some of the problems. I'm not sure if I can do a
    third normal form analysis on this, and am not all that
    experienced therein (though I do know the basics).

    I will give you brownie points for not using anything
    overtly SQL Server-based. ;-)

    First Normal Form: Don't use arrays. If one needs
    multiple instances of an attribute with reference to
    another, put the second attribute in its own relation.[*]
    If two attributes have a many-many relationship, create
    a third relation to represent that relationship, with an
    appropriate key containing both attributes.

    Second Normal Form: Put the data in the right place; if
    an attribute only requires part of a key, put it in with the
    relation that has that key part (or even create a new one),
    not with a relation that has the full key. For example,
    putting an employee's address within an employee-department
    inclusion relation may cause that address to be lost if
    the employee switches departments.

    Third Normal Form: This one's a bit hard to characterize, and
    relates to non-transitive dependence.

    http://en.wikipedia.org/wiki/Databas...n#Normal_forms

    more fully explains these issues; the entire article also contains
    some examples of edit problems when tables are not in second
    normal form.

    [rest snipped]
    [*] admittedly, slavishly following this rule might cause
    unnecessary tables, in certain contexts. For example,
    a polygon properly requires two tables (where I've
    not included the key declarations for brevity):

    CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...);
    CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    ORDER NUMBER(2,0), X NUMBER, Y NUMBER);

    or even three:

    CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...)
    CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    ORDER NUMBER(2,0), POINT_ID NUMBER(8,0));
    CREATE TABLE G_POINT(POINT_ID NUMBER(8,0), X NUMBER, Y NUMBER);

    whereas a single table might be sufficient in
    PostgreSQL, if one doesn't have to do anything too
    complicated like compute the convex hull of a set
    of polygons' point:

    CREATE TABLE G_POLYGON(POLYGON_ID NUMBER(8,0), POINTS POINT[], ...);

    I don't know how standard 'POINT[]' is, though.

    --
    #191, ewill3@earthlink.net
    New Technology? Not There. No Thanks.

    --
    Posted via a free Usenet account from http://www.teranews.com


  2. Re: Linux Advocacy is completely Dead......

    After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:

    > How well VB hews to this standard, I for one can't say.


    Who cares? We have Perl (though I don't really like it much). Even
    better -- Python. I'm just getting into that language, and it looks
    pretty cool.

    Wny monkey around with Billy Basic, or even OO Basic?

    --
    Tux rox!

  3. Re: Linux Advocacy is completely Dead......

    After takin' a swig o' grog, DFS belched out this bit o' wisdom:

    > I'm not a troll.

    -- DFS

    I am not a crook.
    -- Richard M. Nixon

    --
    I did not inhale.
    I did not have sex with that.... woman... Miss Lewinksy.
    -- William Jefferson Clinton


  4. Re: Linux Advocacy is completely Dead......

    Linonut writes:

    > After takin' a swig o' grog, DFS belched out this bit o' wisdom:
    >
    >> I'm not a troll.

    > -- DFS
    >
    > I am not a crook.
    > -- Richard M. Nixon


    With every post I make I prove I am neither clever nor a comedian
    -- lienonut

  5. Re: Linux Advocacy is completely Dead......

    It was on, or about, Tue, 18 Sep 2007 11:28:47 +0000, that as I was
    halfway through a large jam doughnut, Linonut wrote:

    > After takin' a swig o' grog, DFS belched out this bit o' wisdom:
    >
    >> I'm not a troll.

    > -- DFS
    >
    > I am not a crook.
    > -- Richard M. Nixon


    “Two years from now, spam will be solved,”
    -- Bill Gates, January 2004


    --
    Quack admits to trolling: "Or are you trolling me back here?"
    Newsgroups: comp.os.linux.advocacy
    Message-ID:
    Date: Sun, 16 Sep 2007 18:15:07


  6. Re: Linux Advocacy is completely Dead......

    The Ghost In The Machine wrote:
    > Linonut wrote:
    >> High Plains Thumper belched:
    >>> Linonut wrote:
    >>>> High Plains Thumper belched:
    >>>>
    >>>>> But then I forgot, Winvocates don't know how to work
    >>>>> in text mode. If you can't see it graphically, you
    >>>>> are hopelessly lost. You haven't graduated yet from
    >>>>> BASIC (visual, that is). :-)
    >>>> Hint: Visual Basic isn't BASIC.
    >>>
    >>> I was being facetious, din't you notice the smiley?

    >>
    >> Yeah, but I needed a Google-able nugget.

    >
    > Just as a bit of personal historical perspective:
    >
    > [1] HP Basic. I'm not sure if this is it's official name, but
    > basically it was a paper punched tape that could be loaded
    > into HP 21xx computer systems (we had three: a 2114B, a 211B,
    > and a 21mx, which had brand new semiconductor RAM -- a novelty
    > way back then) in the late 1970's. Its main claim to fame was
    > the extremely limited variable name space; 'A0', 'DIM A(10)',
    > and 'A$' are examples thereof. The error diagnoistics were
    > appalling by today's standards; one had to look up the error
    > codes in a pamphlet. "ERROR 76 IN LINE 20", for instance,
    > meant that one needed more DATA statements, if memory serves.
    > (It's admittedly an improvement over Apple ]['s "SYNTAX ERROR"
    > diagnostic, though not by much.)
    >
    > And all of this in 16 kB of RAM. (Actually, 8 kilowords, with
    > each word being 16 bits.) The HP 21xx series wasn't even
    > stack based, but we'll go into that another time. :-)


    I remember using HP BASIC on an HP-85 microcomputer. It was for
    my directed research project, computer interfacing with
    laboratory instrumentation back in 1981. I used it to do Fourier
    Series analysis of model rocket thrust data obtained through a
    Keithley high speed voltmeter interfaced to the HP-85 via the
    GPIB bus. (HP called it the HPIB - Hewlett-Packard
    Instrumentation Bus.)

    I believe the HP-85 was 8-bit with 8 kB RAM. It used mini data
    cassette cartridge for data and software storage.

    > [2] VMS Basic. I don't know the details, but VMS had
    > everything else: COBOL, Fortran, Pascal, assembly language, at
    > least *two* C compilers, all able to call each other.
    >
    > [3] Apple ][. Integer-based BASIC with some interesting
    > capabilities buried thereinto.
    >
    > [4] Apple ///. Floating-point BASIC. This one actually
    > innovated the notion of deferring syntax check until the
    > program was run. It also made the 'LET' keyword optional.
    >
    > [5] IBM Basic. There were several variants of this, from a
    > ROM-based BASICA in early PCs to a GW-BASIC.


    Tektronix had their own BASIC language on their storage tube
    technology computers (4020, 4054). Those generated true vector
    graphics. We used them on wind tunnel tests. For smaller tests
    like the DC-9 "boat-tail" study we did, the smaller 4020 did the
    data acquisition and the 19" display 4054 did the graphics
    plotting. For larger tests, we'd either use Rockwell
    Rocketdyne's computer system with 4054 or Perkin-Elmer 3220/3230
    minicomputer, with 4054.

    I've used GW-BASIC and BASIC-A. Similar to CP/M-80 BASIC except
    one could also do graphics. I liked BASIC, because one could do
    quick and dirty stuff like pre-process ASCII data, grunt work stuff.

    Out of curiosity, I installed bwBASIC and yaBASIC in Ubuntu.
    bwBASIC reminds me of Perkin-Elmer BASIC.

    I remember one supervisor, who wanted to autorun BASIC programs
    but did not know how. I figured it out for him. I created a
    Perkin-Elmer CSS, left a blank line after the PE-BASIC interpeter
    load line. It would of all things write to line 2 of the file
    (software string announcement). Then after that, adding a few
    lines to load the basic program and execute.

    That was back in the days when they allowed one to play games
    during lunch and after work. Management thought it was healthy,
    got people acquainted with using the computer.

    Then all that ceased with a change in corporate management.
    Morale changed significantly (for the worse). No wonder why
    McDonnell Douglas became uncompetitive. Ask any Boeing person. :-)

    --
    HPT

  7. Re: Linux Advocacy is completely Dead......

    Linonut wrote:

    >After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
    >
    >> How well VB hews to this standard, I for one can't say.

    >
    >Who cares? We have Perl (though I don't really like it much). Even
    >better -- Python. I'm just getting into that language, and it looks
    >pretty cool.
    >
    >Wny monkey around with Billy Basic, or even OO Basic?


    One version not on Ghost's list is M$ QuickBasic, from the late 80's,
    which is my favorite M$ program ever. It was so cool to be able to
    quickly and easily pound-out stand-alone .exe's for the PC, and it has
    everything you need to make reasonably structured programs. I
    occasionally still use it at work, believe it or not...


  8. Re: Linux Advocacy is completely Dead......

    After takin' a swig o' grog, chrisv belched out this bit o' wisdom:

    > Linonut wrote:
    >
    >>After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
    >>
    >>> How well VB hews to this standard, I for one can't say.

    >>
    >>Who cares? We have Perl (though I don't really like it much). Even
    >>better -- Python. I'm just getting into that language, and it looks
    >>pretty cool.
    >>
    >>Wny monkey around with Billy Basic, or even OO Basic?

    >
    > One version not on Ghost's list is M$ QuickBasic, from the late 80's,
    > which is my favorite M$ program ever. It was so cool to be able to
    > quickly and easily pound-out stand-alone .exe's for the PC, and it has
    > everything you need to make reasonably structured programs. I
    > occasionally still use it at work, believe it or not...


    But it is still... BASIC.

    --
    Tux rox!

  9. Re: Linux Advocacy is completely Dead......

    In comp.os.linux.advocacy, Linonut

    wrote
    on Tue, 18 Sep 2007 16:39:56 GMT
    :
    > After takin' a swig o' grog, chrisv belched out this bit o' wisdom:
    >
    >> Linonut wrote:
    >>
    >>>After takin' a swig o' grog, The Ghost In The Machine belched out this bit o' wisdom:
    >>>
    >>>> How well VB hews to this standard, I for one can't say.
    >>>
    >>>Who cares? We have Perl (though I don't really like it much). Even
    >>>better -- Python. I'm just getting into that language, and it looks
    >>>pretty cool.
    >>>
    >>>Wny monkey around with Billy Basic, or even OO Basic?

    >>
    >> One version not on Ghost's list is M$ QuickBasic, from the late 80's,
    >> which is my favorite M$ program ever. It was so cool to be able to
    >> quickly and easily pound-out stand-alone .exe's for the PC, and it has
    >> everything you need to make reasonably structured programs. I
    >> occasionally still use it at work, believe it or not...


    Hmm...can't say I've heard of it. :-) Not too surprising.

    >
    > But it is still... BASIC.
    >


    I'll have to reread the ISO spec to see what makes
    Basic basic...but they're beginning to all look the
    same to me. :-)

    Of course, the differences between the Basic
    or Fortran statement

    A = B.C(D)

    the (presumably) Object Pascal statement[*]

    a := b.c(d)

    the Java or Python statement

    a = b.c(d);

    the Ruby statement

    $a = $b.c($d); (or @a = @b.c(@d); }

    and the Perl statement

    $a = $b->c($d);

    are mostly syntactical, but e.g. Perl has quite a bit of
    pattern matching that Basic doesn't.

    The only odd man out in this sequence might be Smalltalk,
    which can use

    a := b c funcarg: d

    if c is declared as

    c: funcarg
    ...

    in addition to the more conventional

    a := b.c(d)

    See any major differences? :-) I don't.
    [*] Structure field accessors use '.', so this is a reasonable
    extension.

    --
    #191, ewill3@earthlink.net
    fortune: not found

    --
    Posted via a free Usenet account from http://www.teranews.com


  10. Re: Linux Advocacy is completely Dead......

    [snips]

    On Mon, 17 Sep 2007 08:08:22 -0700, The Ghost In The Machine wrote:

    >> EMAIL VARCHAR(50) NULL

    >
    > No phone numbers? Or is that separate?


    How about simply email addresses? Note that an email address's length is
    in fact constrained - to 320 characters:

    A local part (user) of up to 64 chars
    A host part of up to 255 characters
    An @

    His field isn't even long enough for the local part.

    >> CREATE TABLE TL_CNTCT_TITLE
    >> (
    >> TITLE VARCHAR(50) NOT NULL ,
    >> TITLE_LDSC VARCHAR(50) NOT NULL

    >
    > This is ridiculous. The long description should not be the same size as
    > the short description.


    Does seem a tad odd.

  11. Re: Linux Advocacy is completely Dead......

    On 2007-09-19, Kelsey Bjarnason wrote:
    >>> EMAIL VARCHAR(50) NULL

    >>
    >> No phone numbers? Or is that separate?

    >
    > How about simply email addresses? Note that an email address's length is
    > in fact constrained - to 320 characters:
    >
    > A local part (user) of up to 64 chars
    > A host part of up to 255 characters
    > An @
    >
    > His field isn't even long enough for the local part.


    You are assuming that the email address isn't further constrained
    outside the database. Note that his other fields included a department
    and title, but not a company, which indicates this may have been for an
    internal contact list, and so the email address may not include the @
    and host, and may be subject to internal conventions that limit the
    local part.

  12. Re: Linux Advocacy is completely Dead......

    In comp.os.linux.advocacy, Kelsey Bjarnason

    wrote
    on Wed, 19 Sep 2007 09:30:16 -0700
    :
    > [snips]
    >
    > On Mon, 17 Sep 2007 08:08:22 -0700, The Ghost In The Machine wrote:
    >
    >>> EMAIL VARCHAR(50) NULL

    >>
    >> No phone numbers? Or is that separate?

    >
    > How about simply email addresses? Note that an email address's length is
    > in fact constrained - to 320 characters:
    >
    > A local part (user) of up to 64 chars
    > A host part of up to 255 characters
    > An @
    >
    > His field isn't even long enough for the local part.


    One might have to generalize the concept, from phones and
    beepers to IM handles.

    >
    >>> CREATE TABLE TL_CNTCT_TITLE
    >>> (
    >>> TITLE VARCHAR(50) NOT NULL ,
    >>> TITLE_LDSC VARCHAR(50) NOT NULL

    >>
    >> This is ridiculous. The long description should not be the same size as
    >> the short description.

    >
    > Does seem a tad odd.


    Aye. PostgreSQL offers the "TEXT" type -- dunno how
    standard that is, but it is of indefinite length.

    --
    #191, ewill3@earthlink.net
    Is it cheaper to learn Linux, or to hire someone
    to fix your Windows problems?

    --
    Posted via a free Usenet account from http://www.teranews.com


  13. Re: Linux Advocacy is completely Dead......

    The Ghost In The Machine wrote:
    > In comp.os.linux.advocacy, DFS


    > ObYuck: Yuck. Can't your database handle 'CONTACT' like
    > normal DB systems? :-P Then again...I'd have to look;
    > it might be a keyword.


    Not a keyword. I was adhering to the client's column naming conventions,
    which often remove vowels. I got griped at in the past for not doing so,
    and these tables are part of a very important db that will
    [probably]/[eventually] be moved to Oracle. So I sucked it up and did it
    their way



    >> CREATE TABLE TL_CNTCT
    >> (
    >> CNTCT_ID NUMBER(8,0) NOT NULL ,

    >
    > Not unreasonable thus far. However, restricting it to
    > 8 digits looks a bit arbitrary. 2^31 = 2147483648 --
    > 10 digits.


    8 digits will let me assign 99,999,999 contacts. I don't have that many
    friends - do you



    > The identifier probably should be expanded to
    > 'CONTACT_ID' in a perfect world.


    Probably so. As I developed code, I often typed CONTACT_ID without
    thinking.



    >> CNTCT_TYP VARCHAR(5) NOT NULL ,

    >
    > I don't like enumerated types represented as varchars.
    > (In our database, we have a mix. Some of our
    > enumerated/quasi-enumerateds are represented as numbers,
    > with a lookup table for convenience. Others are multichar
    > codes much like CNTCT_TYP. Not a lot I can do about it;
    > we convert them when we can.)


    That column has 2 values restricted by a check constraint (not shown).




    >> DEPT VARCHAR(20) NOT NULL ,

    >
    > A quasi-enumerated type. This probably should be a
    > foreign key. Is there a TL_DEPT table?


    There is. Didn't show it.



    > There are also scoping issues -- where's
    > the company for this department?


    Internal system - not for sale.



    >> TITLE VARCHAR(30) NOT NULL ,

    >
    > Interesting notion. Are we supposed to assume 'The Duke Of
    > Wellington' fits in here? Or is this restricted to 'Mr',
    > 'Mrs', 'Miss', 'Mz'?


    Revenue Manager, Field Consultant, etc.



    >> LAST_NM VARCHAR(35) NOT NULL ,

    >
    > Standard surname stuff.
    >
    >> FIRST_NM VARCHAR(35) NOT NULL ,

    >
    > Standard firstname stuff. No middle initial?
    >
    >> ADDR1 VARCHAR(35) NOT NULL ,

    >
    > I suppose this is more generic than 'NUMBER/STREET/UNIT', but
    > am wondering if 35 is enough. Then again...


    Some of these columns are derivative/downstream of other systems in place at
    this client. They use 35 for address lines.



    >> ADDR2 VARCHAR(35) NULL ,

    >
    > Compromise, thy name is address field. Also, is the NULL a
    > typo, or an indication that this field may in fact be null?
    > I'm hoping the latter.


    ADDR2 is NULLABLE.



    >> CITY VARCHAR(30) NOT NULL ,

    >
    > Another quasi-enumerated type, though so large there's
    > probably no point in representing it as such.
    >
    >> STATECD VARCHAR(2) NOT NULL ,

    >
    > Extremely restrictive. Also, no provision for
    > international provinces.


    System is USA only - at least for now.



    >> ZIP VARCHAR(9) NOT NULL ,

    >
    > Ditto.


    Ditto.



    >> EMAIL VARCHAR(50) NULL

    >
    > No phone numbers? Or is that separate?


    Separate table.



    >> );
    >>
    >> ALTER TABLE TL_CNTCT
    >> ADD CONSTRAINT PK_TL_CNTCT PRIMARY KEY
    >> ( CNTCT_ID );

    >
    > OK.
    >
    >>
    >> CREATE UNIQUE INDEX UIDX_CONTACT ON TL_CNTCT
    >> ( LAST_NM, FIRST_NM, ADDR1 );

    >
    > OK, I suppose. I'd key on ADDR2 but with a NULLable field
    > in an index things get a little interesting. This doesn't
    > look very reliable.


    How so? You'd be surprised at how many Ghost Machines there are, but they
    all have a different address.



    >> -----------------------------------------------------------------------------
    >> CREATE TABLE TL_CNTCT_PHONE

    >
    > Ah, phone numbers.
    >
    >> (
    >> PH_ID NUMBER(8,0) NOT NULL ,

    >
    > A little odd. Of course there is the possbility that two
    > or more contacts could share one phone number (if they
    > happen to share a cubicle booth or do not have direct
    > lines and thus have to all go though the company's main
    > switchboard), so that's probably OK.


    This PH_ID was created for one purpose - I let the user (see below) choose
    which contact phone number they want to display onscreen. It's a small but
    very sweet feature, and is one of the many reasons I make the big bucks.

    CREATE TABLE TT_CNTCT_USR_PH
    (
    USR_ID NUMBER(8,0) NOT NULL ,
    PH_ID NUMBER(8,0) NOT NULL ,
    DSPLY VARCHAR(1) NOT NULL
    );

    ALTER TABLE TT_CNTCT_USR_PH
    ADD CONSTRAINT PK_TT_CNTCT_USR_PH PRIMARY KEY
    ( USR_ID, PH_ID, DSPLY );





    >> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >
    > Inconsistent foreign key; should be NUMBER(8,0).


    I tweaked it manually a bit before posting it, and missed some things.



    >> PH_TYP VARCHAR(10) NOT NULL ,

    >
    > Another enumerated type.
    >
    >> PH_NBR VARCHAR(25) NOT NULL ,

    >
    > I suppose this is tolerable, and does allow for
    > extensions and international dialing codes if necessary.
    >
    >> );





    >> ALTER TABLE TL_CNTCT_PHONE
    >> ADD CONSTRAINT PK_TL_CNTCT_PH PRIMARY KEY
    >> ( PH_ID );
    >>
    >> CREATE UNIQUE INDEX UIDX_CNTCT_PH ON TL_CNTCT_PHONE
    >> ( CNTCT_ID, PH_TYP );

    >
    > No index on PH_TYP and PH_NBR? With Caller-ID, one might
    > want that.


    PH_TYP maybe.



    >> -----------------------------------------------------------------------------
    >> CREATE TABLE TL_CNTCT_TITLE
    >> (
    >> TITLE VARCHAR(50) NOT NULL ,
    >> TITLE_LDSC VARCHAR(50) NOT NULL

    >
    > This is ridiculous. The long description should not be
    > the same size as the short description.
    >
    >> );


    I screwed up here. The longest of the 70 titles in the table is 22
    characters, and the longest description is 41 characters.



    >> ALTER TABLE TL_CNTCT_TITLE
    >> ADD CONSTRAINT PK_TL_CNTCT_TITLE PRIMARY KEY
    >> ( TITLE );
    >>
    >> CREATE UNIQUE INDEX UIDX_TITLE_LDSC ON TL_CNTCT_TITLE
    >> ( TITLE_LDSC );

    >
    > OK, though I'm not thrilled.


    Just keeping the data clean, which has made life much easier.



    >> -----------------------------------------------------------------------------
    >> CREATE TABLE TL_CNTCT_CHAIN

    >
    > Not sure what this one's for.


    Assign the contacts to the restaurant chains.



    >> (
    >> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >
    > Another inconsistent foreign key.


    You mean the data size? The tables are actually in Access right now, and
    the VB code I wrote to generate the Oracle DDL defaults to 5,0.



    >> CHAIN_CODE VARCHAR(2) NOT NULL

    >
    > Not sure what this is, but this is probably a
    > quasi-enumerated type again.
    >
    >> );
    >>
    >> ALTER TABLE TL_CNTCT_CHAIN
    >> ADD CONSTRAINT PK_TL_CNTCT_CH PRIMARY KEY
    >> ( CNTCT_ID, CHAIN_CODE );

    >
    > This table is all index, then. Good for storage.





    >> -----------------------------------------------------------------------------
    >> CREATE TABLE TL_CNTCT_STATE

    >
    > This one needs to be extended to include country; state
    > should be changed to province, or left as is.


    No. It's similar to TL_CNTCT_CHAIN.



    >> (
    >> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >
    > Another inconsistent foreign key.
    >
    >> STATECD VARCHAR(20) NOT NULL

    >
    > This looks like a typo. Did you mean VARCHAR(2)?


    Another screwup.



    >> );
    >>
    >> ALTER TABLE TL_CNTCT_STATE
    >> ADD CONSTRAINT PK_TL_CNTCT_ST PRIMARY KEY
    >> ( CNTCT_ID, STATECD );

    >
    > Another all index table.
    >
    > * * *
    >
    > There is a 'TEXT' type that PostgreSQL supports -- not sure
    > how standard it is. Such might be useful for TITLE_LDSC.
    >
    > As already noted, this screams for internationalization.


    This structure may be built upon or updated for non-American facilities, but
    for now it's US only.




    >> -----------------------------------------------------------------------------
    >>
    >>
    >> Talk's cheap, and you're all hot air chump, and you'll slink away
    >> as fast as possible. So did Rex Ballard, who called my work trivial.
    >> And Jabba Bailo.

    >
    > Not sure this is trivial, but it's definitely easy to
    > spot some of the problems.


    The "problems" you spotted are mostly trivialities related to column sizing,
    or matters of opinion/debate. This one is pretty much clean, and therefore
    so is the data - one way to tell is when I write queries I never have to do
    OUTER JOINs, and even complex queries run very fast, and the overall db size
    is small.

    I've created much worse designs, believe me - and they cost a lot in the
    end.

    Also, I posted only 5 tables related to Contacts; the entire structure is 80
    tables.

    Anyway, the actual assignment here was for Dumb Willie to take this database
    and build an interface around it using the software tool of his choice. Of
    course he ran away.



    > I'm not sure if I can do a
    > third normal form analysis on this, and am not all that
    > experienced therein (though I do know the basics).
    >
    > I will give you brownie points for not using anything
    > overtly SQL Server-based. ;-)


    I fought to get this data system deployed in Oracle, but they weren't
    buying, and it's been in Access for nearly 2 years running just fine. No
    data loss - yet. I warn them every few months, but it's going to take a
    catastrophic loss to make them understand.



    > First Normal Form: Don't use arrays. If one needs
    > multiple instances of an attribute with reference to
    > another, put the second attribute in its own relation.[*]
    > If two attributes have a many-many relationship, create
    > a third relation to represent that relationship, with an
    > appropriate key containing both attributes.
    >
    > Second Normal Form: Put the data in the right place; if
    > an attribute only requires part of a key, put it in with the
    > relation that has that key part (or even create a new one),
    > not with a relation that has the full key. For example,
    > putting an employee's address within an employee-department
    > inclusion relation may cause that address to be lost if
    > the employee switches departments.
    >
    > Third Normal Form: This one's a bit hard to characterize, and
    > relates to non-transitive dependence.
    >
    > http://en.wikipedia.org/wiki/Databas...n#Normal_forms
    >
    > more fully explains these issues; the entire article also contains
    > some examples of edit problems when tables are not in second
    > normal form.


    1. Eliminate repeating groups
    2. Eliminate redundant data
    3. Eliminate columns not dependent on key
    4. Isolate independent multiple relationships




    >[*] admittedly, slavishly following this rule might cause
    > unnecessary tables, in certain contexts. For example,
    > a polygon properly requires two tables (where I've
    > not included the key declarations for brevity):
    >
    > CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...);
    > CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    > ORDER NUMBER(2,0), X NUMBER, Y NUMBER);
    >
    > or even three:
    >
    > CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...)
    > CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    > ORDER NUMBER(2,0), POINT_ID NUMBER(8,0));
    > CREATE TABLE G_POINT(POINT_ID NUMBER(8,0), X NUMBER, Y NUMBER);
    >
    > whereas a single table might be sufficient in
    > PostgreSQL, if one doesn't have to do anything too
    > complicated like compute the convex hull of a set
    > of polygons' point:
    >
    > CREATE TABLE G_POLYGON(POLYGON_ID NUMBER(8,0), POINTS POINT[],
    > ...);
    >
    > I don't know how standard 'POINT[]' is, though.



    CREATE OR REPLACE VIEW V_POLYGONS AS
    SELECT P.POLYGON_ID, P.POLYGON_NM, PT.X, PT.Y
    FROM G_POLYGON P, G_POLYGON_POINT PP, G_POINT PT
    WHERE P.POLYGON_ID = PP.POLYGON_ID
    AND PP.POINT_ID = PT.POINT_ID
    /




  14. Re: Linux Advocacy is completely Dead......

    In comp.os.linux.advocacy, DFS

    wrote
    on Thu, 20 Sep 2007 00:23:38 -0400
    :
    > The Ghost In The Machine wrote:
    >> In comp.os.linux.advocacy, DFS

    >
    >> ObYuck: Yuck. Can't your database handle 'CONTACT' like
    >> normal DB systems? :-P Then again...I'd have to look;
    >> it might be a keyword.

    >
    > Not a keyword. I was adhering to the client's column naming conventions,
    > which often remove vowels. I got griped at in the past for not doing so,
    > and these tables are part of a very important db that will
    > [probably]/[eventually] be moved to Oracle. So I sucked it up and did it
    > their way
    >
    >
    >
    >>> CREATE TABLE TL_CNTCT
    >>> (
    >>> CNTCT_ID NUMBER(8,0) NOT NULL ,

    >>
    >> Not unreasonable thus far. However, restricting it to
    >> 8 digits looks a bit arbitrary. 2^31 = 2147483648 --
    >> 10 digits.

    >
    > 8 digits will let me assign 99,999,999 contacts. I don't have that many
    > friends - do you


    Me, you, no. However, how about a very large enterprise?
    In any event, that extra digit costs nothing -- mostly
    because the database is presumably using 4 bytes anyway.

    In any event, the number of people on this slightly
    mildewed marble has already exceeded the capability of a
    32-bit integer. Fortunately, most of them are unlikely
    to be placed in this database. :-)

    >
    >
    >
    >> The identifier probably should be expanded to
    >> 'CONTACT_ID' in a perfect world.

    >
    > Probably so. As I developed code, I often typed CONTACT_ID without
    > thinking.
    >


    So there's a problem already; development time is slowed.
    Slightly, to be sure -- but slowed all the same.

    >
    >
    >>> CNTCT_TYP VARCHAR(5) NOT NULL ,

    >>
    >> I don't like enumerated types represented as varchars.
    >> (In our database, we have a mix. Some of our
    >> enumerated/quasi-enumerateds are represented as numbers,
    >> with a lookup table for convenience. Others are multichar
    >> codes much like CNTCT_TYP. Not a lot I can do about it;
    >> we convert them when we can.)

    >
    > That column has 2 values restricted by a check constraint (not shown).
    >


    Hmm...better than nothing.

    >
    >
    >
    >>> DEPT VARCHAR(20) NOT NULL ,

    >>
    >> A quasi-enumerated type. This probably should be a
    >> foreign key. Is there a TL_DEPT table?

    >
    > There is. Didn't show it.
    >


    OK.

    >
    >
    >> There are also scoping issues -- where's
    >> the company for this department?

    >
    > Internal system - not for sale.
    >


    OK.

    >
    >
    >>> TITLE VARCHAR(30) NOT NULL ,

    >>
    >> Interesting notion. Are we supposed to assume 'The Duke Of
    >> Wellington' fits in here? Or is this restricted to 'Mr',
    >> 'Mrs', 'Miss', 'Mz'?

    >
    > Revenue Manager, Field Consultant, etc.
    >


    Questionable as to whether those are titles or employment.
    Perhaps I'm too much of a classicist, but I could want a
    better term here.

    >
    >
    >>> LAST_NM VARCHAR(35) NOT NULL ,

    >>
    >> Standard surname stuff.
    >>
    >>> FIRST_NM VARCHAR(35) NOT NULL ,

    >>
    >> Standard firstname stuff. No middle initial?
    >>
    >>> ADDR1 VARCHAR(35) NOT NULL ,

    >>
    >> I suppose this is more generic than 'NUMBER/STREET/UNIT', but
    >> am wondering if 35 is enough. Then again...

    >
    > Some of these columns are derivative/downstream of other systems in place at
    > this client. They use 35 for address lines.
    >


    OK.

    >
    >
    >>> ADDR2 VARCHAR(35) NULL ,

    >>
    >> Compromise, thy name is address field. Also, is the NULL a
    >> typo, or an indication that this field may in fact be null?
    >> I'm hoping the latter.

    >
    > ADDR2 is NULLABLE.
    >


    OK.

    >
    >
    >>> CITY VARCHAR(30) NOT NULL ,

    >>
    >> Another quasi-enumerated type, though so large there's
    >> probably no point in representing it as such.
    >>
    >>> STATECD VARCHAR(2) NOT NULL ,

    >>
    >> Extremely restrictive. Also, no provision for
    >> international provinces.

    >
    > System is USA only - at least for now.
    >


    OK. But that's a limitation they'll have to upgrade later.

    >
    >
    >>> ZIP VARCHAR(9) NOT NULL ,

    >>
    >> Ditto.

    >
    > Ditto.
    >


    OK.

    >
    >
    >>> EMAIL VARCHAR(50) NULL

    >>
    >> No phone numbers? Or is that separate?

    >
    > Separate table.
    >


    Yes, I noticed that later on.

    >
    >
    >>> );
    >>>
    >>> ALTER TABLE TL_CNTCT
    >>> ADD CONSTRAINT PK_TL_CNTCT PRIMARY KEY
    >>> ( CNTCT_ID );

    >>
    >> OK.
    >>
    >>>
    >>> CREATE UNIQUE INDEX UIDX_CONTACT ON TL_CNTCT
    >>> ( LAST_NM, FIRST_NM, ADDR1 );

    >>
    >> OK, I suppose. I'd key on ADDR2 but with a NULLable field
    >> in an index things get a little interesting. This doesn't
    >> look very reliable.

    >
    > How so? You'd be surprised at how many Ghost Machines there are, but they
    > all have a different address.
    >


    Aye. But you'd be surprised how often mailing address
    managers misspell my street name. :-P And even if they
    managed to spell it correctly, there's the question of
    various extra spaces therein:

    123 Anystreet Lane
    123 Anystreet Lane
    123Anystreet Lane

    etc.

    Of course, the flip side is that there's a few rural roads
    and such that don't neatly fit into this formatting.

    >
    >
    >>> -----------------------------------------------------------------------------
    >>> CREATE TABLE TL_CNTCT_PHONE

    >>
    >> Ah, phone numbers.
    >>
    >>> (
    >>> PH_ID NUMBER(8,0) NOT NULL ,

    >>
    >> A little odd. Of course there is the possbility that two
    >> or more contacts could share one phone number (if they
    >> happen to share a cubicle booth or do not have direct
    >> lines and thus have to all go though the company's main
    >> switchboard), so that's probably OK.

    >
    > This PH_ID was created for one purpose - I let the user (see below) choose
    > which contact phone number they want to display onscreen. It's a small but
    > very sweet feature, and is one of the many reasons I make the big bucks.
    >
    > CREATE TABLE TT_CNTCT_USR_PH
    > (
    > USR_ID NUMBER(8,0) NOT NULL ,
    > PH_ID NUMBER(8,0) NOT NULL ,
    > DSPLY VARCHAR(1) NOT NULL
    > );
    >
    > ALTER TABLE TT_CNTCT_USR_PH
    > ADD CONSTRAINT PK_TT_CNTCT_USR_PH PRIMARY KEY
    > ( USR_ID, PH_ID, DSPLY );
    >


    OK.

    >
    >
    >
    >
    >>> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >>
    >> Inconsistent foreign key; should be NUMBER(8,0).

    >
    > I tweaked it manually a bit before posting it, and missed some things.
    >


    Yep.

    >
    >
    >>> PH_TYP VARCHAR(10) NOT NULL ,

    >>
    >> Another enumerated type.
    >>
    >>> PH_NBR VARCHAR(25) NOT NULL ,

    >>
    >> I suppose this is tolerable, and does allow for
    >> extensions and international dialing codes if necessary.
    >>
    >>> );

    >
    >
    >
    >
    >>> ALTER TABLE TL_CNTCT_PHONE
    >>> ADD CONSTRAINT PK_TL_CNTCT_PH PRIMARY KEY
    >>> ( PH_ID );
    >>>
    >>> CREATE UNIQUE INDEX UIDX_CNTCT_PH ON TL_CNTCT_PHONE
    >>> ( CNTCT_ID, PH_TYP );

    >>
    >> No index on PH_TYP and PH_NBR? With Caller-ID, one might
    >> want that.

    >
    > PH_TYP maybe.
    >
    >
    >
    >>> -----------------------------------------------------------------------------
    >>> CREATE TABLE TL_CNTCT_TITLE
    >>> (
    >>> TITLE VARCHAR(50) NOT NULL ,
    >>> TITLE_LDSC VARCHAR(50) NOT NULL

    >>
    >> This is ridiculous. The long description should not be
    >> the same size as the short description.
    >>
    >>> );

    >
    > I screwed up here. The longest of the 70 titles in the table is 22
    > characters, and the longest description is 41 characters.
    >


    OK.

    >
    >
    >>> ALTER TABLE TL_CNTCT_TITLE
    >>> ADD CONSTRAINT PK_TL_CNTCT_TITLE PRIMARY KEY
    >>> ( TITLE );
    >>>
    >>> CREATE UNIQUE INDEX UIDX_TITLE_LDSC ON TL_CNTCT_TITLE
    >>> ( TITLE_LDSC );

    >>
    >> OK, though I'm not thrilled.

    >
    > Just keeping the data clean, which has made life much easier.
    >
    >
    >
    >>> -----------------------------------------------------------------------------
    >>> CREATE TABLE TL_CNTCT_CHAIN

    >>
    >> Not sure what this one's for.

    >
    > Assign the contacts to the restaurant chains.
    >


    Hm.

    >
    >
    >>> (
    >>> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >>
    >> Another inconsistent foreign key.

    >
    > You mean the data size?


    Yes.

    > The tables are actually in Access right now, and
    > the VB code I wrote to generate the Oracle DDL defaults to 5,0.
    >
    >
    >
    >>> CHAIN_CODE VARCHAR(2) NOT NULL

    >>
    >> Not sure what this is, but this is probably a
    >> quasi-enumerated type again.
    >>
    >>> );
    >>>
    >>> ALTER TABLE TL_CNTCT_CHAIN
    >>> ADD CONSTRAINT PK_TL_CNTCT_CH PRIMARY KEY
    >>> ( CNTCT_ID, CHAIN_CODE );

    >>
    >> This table is all index, then. Good for storage.

    >
    >
    >
    >
    >>> -----------------------------------------------------------------------------
    >>> CREATE TABLE TL_CNTCT_STATE

    >>
    >> This one needs to be extended to include country; state
    >> should be changed to province, or left as is.

    >
    > No. It's similar to TL_CNTCT_CHAIN.
    >
    >
    >
    >>> (
    >>> CNTCT_ID NUMBER(5,0) NOT NULL ,

    >>
    >> Another inconsistent foreign key.
    >>
    >>> STATECD VARCHAR(20) NOT NULL

    >>
    >> This looks like a typo. Did you mean VARCHAR(2)?

    >
    > Another screwup.
    >


    Ah.

    >
    >
    >>> );
    >>>
    >>> ALTER TABLE TL_CNTCT_STATE
    >>> ADD CONSTRAINT PK_TL_CNTCT_ST PRIMARY KEY
    >>> ( CNTCT_ID, STATECD );

    >>
    >> Another all index table.
    >>
    >> * * *
    >>
    >> There is a 'TEXT' type that PostgreSQL supports -- not sure
    >> how standard it is. Such might be useful for TITLE_LDSC.
    >>
    >> As already noted, this screams for internationalization.

    >
    > This structure may be built upon or updated for non-American facilities, but
    > for now it's US only.
    >
    >
    >
    >
    >>> -----------------------------------------------------------------------------
    >>>
    >>>
    >>> Talk's cheap, and you're all hot air chump, and you'll slink away
    >>> as fast as possible. So did Rex Ballard, who called my work trivial.
    >>> And Jabba Bailo.

    >>
    >> Not sure this is trivial, but it's definitely easy to
    >> spot some of the problems.

    >
    > The "problems" you spotted are mostly trivialities related to column sizing,
    > or matters of opinion/debate. This one is pretty much clean, and therefore
    > so is the data - one way to tell is when I write queries I never have to do
    > OUTER JOINs, and even complex queries run very fast, and the overall db size
    > is small.
    >
    > I've created much worse designs, believe me - and they cost a lot in the
    > end.
    >
    > Also, I posted only 5 tables related to Contacts; the entire structure is 80
    > tables.
    >
    > Anyway, the actual assignment here was for Dumb Willie to take this database
    > and build an interface around it using the software tool of his choice. Of
    > course he ran away.
    >
    >
    >
    >> I'm not sure if I can do a
    >> third normal form analysis on this, and am not all that
    >> experienced therein (though I do know the basics).
    >>
    >> I will give you brownie points for not using anything
    >> overtly SQL Server-based. ;-)

    >
    > I fought to get this data system deployed in Oracle, but they weren't
    > buying, and it's been in Access for nearly 2 years running just fine. No
    > data loss - yet. I warn them every few months, but it's going to take a
    > catastrophic loss to make them understand.
    >


    There will be no loss in Access as long as they don't tweak it.
    You're right; it's not that bad. I can pick out flaws, but
    my stuff is just as flawed -- and it's probably better than
    some; I've seen some HP flatfile stuff that makes one wonder.

    >
    >
    >> First Normal Form: Don't use arrays. If one needs
    >> multiple instances of an attribute with reference to
    >> another, put the second attribute in its own relation.[*]
    >> If two attributes have a many-many relationship, create
    >> a third relation to represent that relationship, with an
    >> appropriate key containing both attributes.
    >>
    >> Second Normal Form: Put the data in the right place; if
    >> an attribute only requires part of a key, put it in with the
    >> relation that has that key part (or even create a new one),
    >> not with a relation that has the full key. For example,
    >> putting an employee's address within an employee-department
    >> inclusion relation may cause that address to be lost if
    >> the employee switches departments.
    >>
    >> Third Normal Form: This one's a bit hard to characterize, and
    >> relates to non-transitive dependence.
    >>
    >> http://en.wikipedia.org/wiki/Databas...n#Normal_forms
    >>
    >> more fully explains these issues; the entire article also contains
    >> some examples of edit problems when tables are not in second
    >> normal form.

    >
    > 1. Eliminate repeating groups
    > 2. Eliminate redundant data
    > 3. Eliminate columns not dependent on key
    > 4. Isolate independent multiple relationships
    >
    >
    >
    >
    >>[*] admittedly, slavishly following this rule might cause
    >> unnecessary tables, in certain contexts. For example,
    >> a polygon properly requires two tables (where I've
    >> not included the key declarations for brevity):
    >>
    >> CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...);
    >> CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    >> ORDER NUMBER(2,0), X NUMBER, Y NUMBER);
    >>
    >> or even three:
    >>
    >> CREATE TABLE G_POLYGON (POLYGON_ID NUMBER(8,0), ...)
    >> CREATE TABLE G_POLYGON_POINT(POLYGON_ID NUMBER(8,0),
    >> ORDER NUMBER(2,0), POINT_ID NUMBER(8,0));
    >> CREATE TABLE G_POINT(POINT_ID NUMBER(8,0), X NUMBER, Y NUMBER);
    >>
    >> whereas a single table might be sufficient in
    >> PostgreSQL, if one doesn't have to do anything too
    >> complicated like compute the convex hull of a set
    >> of polygons' point:
    >>
    >> CREATE TABLE G_POLYGON(POLYGON_ID NUMBER(8,0), POINTS POINT[],
    >> ...);
    >>
    >> I don't know how standard 'POINT[]' is, though.

    >
    >
    > CREATE OR REPLACE VIEW V_POLYGONS AS
    > SELECT P.POLYGON_ID, P.POLYGON_NM, PT.X, PT.Y
    > FROM G_POLYGON P, G_POLYGON_POINT PP, G_POINT PT
    > WHERE P.POLYGON_ID = PP.POLYGON_ID
    > AND PP.POINT_ID = PT.POINT_ID
    > /
    >


    I wasn't going to get into views, but they have their uses
    as transition elements while parts of a system are going
    through an upgrade cycle.

    --
    #191, ewill3@earthlink.net
    If your CPU can't stand the heat, get another fan.

    --
    Posted via a free Usenet account from http://www.teranews.com


  15. Re: Linux Advocacy is completely Dead......

    On Sep 20, 11:36 pm, Rex Ballard wrote:
    > On Sep 16, 3:41 pm, "DFS" wrote:


    > > I don't hate Linux. It's an inferior platform

    Lot's of companies who have been making huge profits by USING Linux
    powered servers would probably disagree with you. Still, you have
    your opinion, and it's pretty clear that you are very much committed
    to Microsoft products and projects. Nothing wrong with that, but your
    position is more appropriate to Comp.OS.Windows.Advocacy. I don't
    post "Ain't Linux Great" articles in COWA, but it seems that Softees
    and WinTrolls can't resist dumbing their turds in our sandbox.


    > > or personal computing is


    Linux and Mac are more similar to each other than either is to
    Windows. When end-users have had the chance to make side-by-side
    comparisons between UNIX (OS/X) and Windows (XP or Vista), the verdict
    seems to be "I'd rather have a Mac" about 70% of the time.

    > > all. Oh, and most OSS apps suck


    Again, you have an opinion, which many very qualified and important
    people would disagree with. There are lots of companies using LAMP
    (Linux, Apache, MySQL, and PHP or PERL) to produce extraordinary
    profits. It's quick, cheap, and very cost-effective. It's reliable,
    secure, stable, and easily managed.

    > >, and the gaming is a joke, and most

    Linux emulates lots of other game machines, and many companies such as
    Atari, Electronic Arts, and Activision make virtual machines or
    wrapper libraries that let Linux users play their games. For many
    people, poor games is a good thing, especially for WORK-stations. If
    you really want to play the latest in really neat games, get a WII.



    > > self-proclaimed pious cola Linux "advocates" are a hypocritical waste of
    > > lying flesh.


    Again, you have an opinion, which you generously share on the
    Comp.os.LINUX.Advocacy group,
    instead of sharing on the comp.os.WINDOWS.Advocacy.group.

    This alone makes you a WinTroll.

    > > But it's a geek dream system, offering total control and
    > > endless tinkering.


    That's fair. Geeks love having lots of control over their machine,
    security that rivals DOD systems, reliability that rivals the
    telephone company, and the ability to access their systems as
    workstations or on laptops, or via remote connections.

    Of course, managers kind of like that they don't have to pay huge
    travel expense budgets to get windows administrators or developers in
    front of the physical machines. They like that most administrative
    tasks, support and troubleshooting, and configuration work can be done
    from 10,000 miles away, by people who have been awake for 2-3 hours,
    and will still be fresh for 6-8 hours more, instead of trying to get
    someone who has just finished working 15 hours to wake up after 3
    hours of sleep to work drive to the office that's 30-60 minutes away,
    so they can work on a "crisis" for another 10-12 hours, along with the
    other 5-6 specialists who must wait and take turns at the console and
    point fingers at each other until the root cause is determined. But
    then again, root cause analysis is such a rare scene in Windows server
    environments. Usually, it's cheaper and faster to just "re-image" the
    hard drive, that it is to actually find out why the system failed and
    make sure it never fails again. Having 5 consultants standing around,
    waiting for their turn at the console, for 8 hours, at $100/hour,
    costs about 4 times as much as a new PC. Add travel costs,
    administative time, and managers' markup, and the price can be higher
    than 8-10 PCs.

    Microsoft HAS been able to benefit from Linux technology though.
    Using Linux as the hosting operating system, and Windows 2003 has made
    it much easier to replace/recover images.

    > > But I've always tried out alternative operating systems, since way back in
    > > 1989. I subscribed to LXF for a year at $106, but now they want $190 and

    I
    1989, what alternatives were these, DRI/GEM? DesqView/X? Mac Finder?
    How about SunOS?
    Did you try Solaris and compare it with Windows 3.1?

    Did you try a side-by-side comparison of Solaris or Interactive Unix
    or UnixWare and Windows NT 3.1?

    How about a comparison between Windows 95 and Linux with FVWM, OLVWM,
    or GNOME.

    Did you do a direct Side-by-Side between Windows NT 4.0 and Red Hat
    Linux 4.2? InfoWorld did and RH won!

    How many people made the CHOICE to use Windows instead of Linux after
    making a side-by-side comparison between the two? How many people
    made the CHOICE to use Linux instead of Windows after making a similar
    comparison?

    There were some, like you who made the comparison between two properly
    configured systems, spent several staff-weeks making some real-world
    and real-problem comparisons to see if Linux was practical, and
    decided to stick with Windows because they had applications that were
    critical, and couldn't be configured to work with Linux.

    This group is the minority at the moment. Most of those who use
    Linux, even if only as a secondary system, or as a server with a
    desktop user interface, have done so after spending hours trying to
    figure out how to get it installed properly, spending days getting it
    configured to do all of the things they wanted, and then spent a month
    or more learning how to use all of the wonderful new Linux
    applications. Some of the Linux apps weren't that great, but others
    were actually pretty nice.




  16. Re: Linux Advocacy is completely Dead......

    Rex Ballard wrote:
    > On Sep 16, 3:41 pm, "DFS" wrote:


    >> CREATE TABLE TL_CNTCT
    >> (
    >> CNTCT_ID NUMBER(8,0) NOT NULL ,
    >> CNTCT_TYP VARCHAR(5) NOT NULL ,
    >> DEPT VARCHAR(20) NOT NULL ,
    >> TITLE VARCHAR(30) NOT NULL ,
    >> LAST_NM VARCHAR(35) NOT NULL ,
    >> FIRST_NM VARCHAR(35) NOT NULL ,
    >> ADDR1 VARCHAR(35) NOT NULL ,
    >> ADDR2 VARCHAR(35) NULL ,
    >> CITY VARCHAR(30) NOT NULL ,
    >> STATECD VARCHAR(2) NOT NULL ,
    >> ZIP VARCHAR(9) NOT NULL ,
    >> EMAIL VARCHAR(50) NULL
    >> );

    >
    > You probably never tried this code on anything other than Windows
    > Access/SQL Server did you.


    That code won't execute in Access. But it will in Oracle, and with some
    minimal changes in SQL Server and DB2.



    > In my world, we need to be able to support Oracle, DB2, SQL Server,
    > and MySQL.
    >
    > Just for grins, I pumped your code into MySQL. It didn't like it at
    > all.


    Excellent! My code's too good for MySQL.

    After fixing that trailing comma you found (the horror!) here's the response
    when I ran that exact DDL in Oracle 9i:
    http://www.angelfire.com/linux/dfs0/Oracle_CNTCT.PNG

    Nothin' but net!



    > Congratulations - you failed yet another portability test!


    I'm glad. It was written explicitly for Oracle, and I wouldn't let my stuff
    be created in MySQL (PostgreSQL might be ok though).



    > You again have demonstrated that you are barely competent to write
    > DDL, you certainly wouldn't qualify as a DBA.


    You found a misplaced comma and I'm disqualified?

    What do you say to people who lie about their work being the basis for Java,
    SSL, and the web browsing industry? Who claim Martin-Marietta developed
    bombs out of notes they stole out of a high-school student's locker? How
    qualified would that kind of person be? Would you consider that person
    trustworthy?



    > mysql> You had a trailing comma. Again, nonportable, and shows that
    > you never tested it on anything other than Access.


    I never tested that code against Access, 'cause I'm smart enough to know it
    won't work in Access.



    > Does this even work on SQL Server?


    This question indicates you know nothing about SQL Server, so stop
    pretending you know everything, and you support all platforms.



    > I'm surprised you didn't create a separate code for e-mail, since most
    > people have more than one.


    For this exercise, I removed a second email column from the Contact table.



    > You didn't really normalize properly (Person and Location should be
    > two tables), but you may have denormalized for performance.


    You think I should split the Contact addresses into a separate table, as in:

    >> CREATE TABLE TL_CNTCT_ADDR
    >> (
    >> ADDR_ID NUMBER(8,0) NOT NULL ,
    >> CNTCT_ID NUMBER(8,0) NOT NULL ,
    >> ADDR_TYP VARCHAR(15) NOT NULL,
    >> ADDR1 VARCHAR(35) NOT NULL ,
    >> ADDR2 VARCHAR(35) NULL ,
    >> CITY VARCHAR(30) NOT NULL ,
    >> STATECD VARCHAR(2) NOT NULL ,
    >> ZIP VARCHAR(9) NOT NULL
    >> );
    >>
    >> ALTER TABLE TL_CNTCT_ADDR
    >> ADD CONSTRAINT PK_TL_CNTCT_ADDR PRIMARY KEY
    >> ( ADDR_ID );
    >>
    >> CREATE UNIQUE INDEX UIDX_CONTACT_ADDR ON TL_CNTCT_ADDR
    >> ( CNTCT_ID, ADDR_TYP );


    so I can record their home address, office address, and mistress' address
    separately?

    If that had been a business requirement I would have.



    > Title is potentially confusing in this form. It could be salutations
    > (Mr, Ms, Mrs, Miss, Dr, Fr,...) or positions (President, Director,
    > Manager, Specialist,...).


    Positions could be confusing as well: President, Manager, doggy-style,
    missionary...



    >> Talk's cheap, and you're all hot air chump, and you'll slink away as
    >> fast as possible. So did Rex Ballard, who called my work trivial.
    >> And Jabba Bailo.

    >
    > Since you mentioned me by name, I thought I'd give myself an hour.


    I appreciate the feedback and all - I really do - but all you came up with
    is one trailing comma, and a few strange warnings generated by a totally
    inferior MySQL program? That's it?

    Oracle loved my code. And so did my Momma.



    > This is a pretty simple example.


    As intended. Yet nobody - least of all Dumb Willie - has risen to the
    original challenge: build a user interface around the structure.



    > Most of my projects involve 20-200
    > tables with anywhere from 5 to 25 fields per table.


    I know, I know: 3 petabytes of storage, 3000 transactions per second,
    multinational, blah blah blah I'm an IT Sooperman!

    You didn't read my reply to Ghost. The full structure is 80 tables, and I
    constructed a nice app around it, with interfaces/links/imports/exports to 6
    other internal systems. It currently has 90 registered users and around
    1000 properties being processed through it. Plus I made at least $100,000
    working on it.

    Like other custom systems I've built for this client, it will be in place
    for years longer than they intended. Know why? 'Cause $100,000 is cheap,
    and it has a lot of features, flexibility, analysis and reports, etc. They
    call it a prototype, but I'll revisit them in 5 years and I can practically
    guarantee it's still in place.

    Only downside is it's fat client Access on Citrix: hard to update and
    deploy, mediocre db server, and doesn't scale very well. But for their
    needs, it's a great fit.



    > I'd also use RSA to lay out the data classes and then use interaction
    > diagrams to map out the flow between the classes. RSA would generate
    > the DAO classes.


    Not familiar with RSA.



    > Still, it's pretty simple to do this in OO Base. Base is a bit like
    > ACCESS, but works with about 2 dozen databases.


    OpenOffice Base is a piece of crap. There's no other way to say it. It
    pales in comparison to Access95, even.



    > And the DDL generated by the CASE tool is portable to all of those
    > databases.


    I'm sure it's a huge mess of spaghetti code. Post some of it so I can watch
    it fail in Oracle and Access and SQL Server.



    > And what exactly did you want to do with the Chain code? Is that
    > chain of command - like manager?


    Like restaurant chain or brand.




  17. Re: Linux Advocacy is completely Dead......



    Rex, your knowledge and time will be better spent not replying to trolls. Even
    if they provoke for replies by refuting, lying to, and ridiculing you, it will
    be best to ignore them. By replying, you're only asking for more (now or in
    the future).

    Just my opinion anyway...

  18. Re: Linux Advocacy is completely Dead......

    On Sat, 22 Sep 2007 21:08:10 +0100, Roy Schestowitz wrote:

    >
    >
    > Rex, your knowledge and time will be better spent not replying to trolls. Even
    > if they provoke for replies by refuting, lying to, and ridiculing you, it will
    > be best to ignore them. By replying, you're only asking for more (now or in
    > the future).


    He'd be better off not spouting fantastic nonsense as if it were true.

    --
    Kier

  19. Re: Linux Advocacy is completely Dead......

    ____/ Kier on Saturday 22 September 2007 21:21 : \____

    > On Sat, 22 Sep 2007 21:08:10 +0100, Roy Schestowitz wrote:
    >
    >>
    >>
    >> Rex, your knowledge and time will be better spent not replying to trolls.
    >> Even if they provoke for replies by refuting, lying to, and ridiculing you,
    >> it will be best to ignore them. By replying, you're only asking for more
    >> (now or in the future).

    >
    > He'd be better off not spouting fantastic nonsense as if it were true.


    *sigh*

    --
    ~~ Best of wishes

    Roy S. Schestowitz | "Far away from home, robots build people"
    http://Schestowitz.com | Open Prospects | PGP-Key: 0x74572E8E
    Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
    http://iuron.com - knowledge engine, not a search engine

  20. Re: Linux Advocacy is completely Dead......

    On Sat, 22 Sep 2007 23:00:13 +0100, Roy Schestowitz wrote:

    > ____/ Kier on Saturday 22 September 2007 21:21 : \____
    >
    >> On Sat, 22 Sep 2007 21:08:10 +0100, Roy Schestowitz wrote:
    >>
    >>>
    >>>
    >>> Rex, your knowledge and time will be better spent not replying to trolls.
    >>> Even if they provoke for replies by refuting, lying to, and ridiculing you,
    >>> it will be best to ignore them. By replying, you're only asking for more
    >>> (now or in the future).

    >>
    >> He'd be better off not spouting fantastic nonsense as if it were true.

    >
    > *sigh*


    Read what he writes, and get your head out of your arse, Roy. He spouts
    fantasies most of the time. Just because he's a Linux advocate doesn't
    mean he can get away with spouting crap.

    --
    Kier


+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast