• We recently purchased a company and are taking over their existing apps, one shocking revelation at a time. My favorite is the fairly simple transactional system for recording orders, approvals and processing dates. The way the various people involved in a transaction are linked to the transaction record is via a table called TransactionStamping. It has a TransNbr, an OrderNbr, I think an ApprovalNbr, and then, oh yes, FIELD1 FIELD2 thru FIELD12 and then DATA0 DATA1 thru DATA15. Depending on the client, you use different combinations of fields to link to things. I began getting hostile when the developers (still from the old company because while we could afford to buy them, we couldn't afford to rewrite their apps) tried to split the same link between tables to two fields for the same customer. (If it's this product get the Budget number from DATA11, but if it's that one use FIELD9.) When I threw a flag, the lead offered to add a DATA16 and also responded "Finally, I do not consider our data model “sketchy” simply because certain complex report requirements test the limits of our transaction stamping capabilities. The good news is for almost clients we have more than enough fields available to accommodate this." Argh.

    [font="Arial"]Are you lost daddy? I asked tenderly.
    Shut up he explained.
    [/font]
    - Ring Lardner