Re: tracking shipments, inventory

From: Alan <not.me_at_rcn.com>
Date: Sat, 25 Dec 2004 13:48:10 -0500
Message-ID: <335r15F3r7c0eU1_at_individual.net>


"-CELKO-" <jcelko212_at_earthlink.net> wrote in message news:1103995429.123451.250060_at_z14g2000cwz.googlegroups.com...
> >> Do you ever feel like you are tilting at windmills on this? Surely
> you must
> feel outnumbered. <<
>
> Nah! More like a crusader :) Knowing what something means and using
> the right words is important. What I do feel is that we have a lot of
> people writing databases who should not be doing the work. When your
> mind-set is still back in the days of paper forms and mag tape files,
> your designs are also back there.
>
> Records and fields do not have keys, constraints or DRI, so you do not
> think about the schema as a whole when you say those words. In this
> case, the schema probably should have been something like:
>
> CREATE TABLE ShipmentHistory
> (shipment_nbr INTEGER NOT NULL,
> shipment_status CHAR(3) NOT NULL
> CHECK (shipment_status IN (..)),
> san INTEGER NOT NULL -- standard address number
> REFERENCES Locations(san)
> ON UPDATE CASCADE,
> start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
> end_date DATE DEFAULT CURRENT_TIMESTAMP, -- null means current
> PRIMARY KEY ((shipment_nbr, start_date));
>
> This is a state-change model that would let you track the shipments.
> That is the nature of time. Various paper forms cause the changes, but
> we do not have to mimic them in this table.
>
> >> My manager refers to an Oracle table as a "file" and it drives me
> nuts. <<
>
> Look at the posting in newsgroups to depress yourself even more. Your
> boss has an excuse and no schema access :)
>

I have to work with COBOL programmers, and I have literally given up trying to explain relational concepts to them. They mostly have the attitude that they don't want to learn anything else at this stage in their careers (a concept that baffles me, as I am always looking to learn something). So, I wind up modifying my questions and explanations so they can understand what I am talking about. At least they understand the notion of a key. They freely use the terms records and files, but they don't always mean rows and tables. When they say 'header record", I really get scared, because I don't know if they mean there will be three-part bunches of information (header, detail, and sumary) or if they mean a row that just contains column names. It takes some probing, and often, a "show me a sample" so I can figure out what they are doing. There is one programmer who understands relational and willingly participates (he has even learned SQL), and another who does understand but prefers to pretend that he doesn't. Received on Sat Dec 25 2004 - 19:48:10 CET

Original text of this message