236263d7   
   From: emurphy42@socal.rr.com   
      
   --CELKO-- wrote:   
      
   >>> Hi, I have a table that contains order information, each row contains   
   information about a detail item that's been order but the key is order_id and   
   line_nbr.  <<   
   >   
   > Line number, as it the PHYSICAL location from a PHYSICAL piece of   
   > paper or input screen? This is a common newbie design error that leads   
   > to extra code and lots of screw ups.   
   >   
   > The customer is actually ordering the item and does not care about a   
   > line number.  This is confusing the car with the parking space.   
      
   Routinely false in practice.  The customer submits paperwork with the   
   items in whatever order they please, and expects you to generate related   
   paperwork with the items in the same order (for matching up).   
      
   > You are supposed to be build a LOGICAL data model, so you should have   
   > a key made up of (order_id, item_nbr) where item number is your SKU,   
   > UPC, EAN or other industry standard product identifier.  Nothing to do   
   > wiht the paper forms!   
      
   Some systems may want to use a less restrictive key, e.g. one customer   
   places one order for two destinations, each getting the same item.  You   
   can change the key to (order_id, destination_id, item_nbr), but at some   
   point it's more practical to just use (order_id, artificial_line_id) and   
   be done with it.   
      
   That said, if the more general case, you should subject physical IDs to   
   this sort of evaluation, and avoid using them /just/ because the old   
   business processes used them.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)