This is the 72nd (72? Nearly 6 years…) T-SQL Tuesday, started by Adam Machanic. Each month, someone sets a topic – this month, Mickey Stuewe (Blog|@SQLMickey) has set the topic “Data Modelling Gone Wrong”.
I noticed this rather too late to do a proper post, so I’ll just mention a couple of things I’ve seen. These are from the past – I’m sure nobody’s doing anything quite so unpleasant any more!
Field named Field
Nothing to do with agriculture, I promise! I came across a table that had, in addition to an ID field, various more useful fields, the following group of fields (in order):
- Field3
- Field1
- Field2
Yes, those really were the names, and that really was the order in which they appeared in the table definition. I have no idea how that came to be. Supporting documentation was never found.
Multi-purpose / Overloaded Fields
Once upon a time, I was working on a system which had a big table full of address-type data, for multiple different entity types (banks, solicitors, customers, clients etc) – something over a dozen different address “types”. The tricky part was that sometimes fields were repurposed – for example, the Fax Number field for a particular address type would actually be some other internal reference number. Oh, and the only documentation for this was to be had by reading the source code of the applications that interacted with this data.
My Plea
Please, for the sake of everyone’s sanity, don’t do this sort of thing.
The Lone DBA 
Pingback: T-SQL Tuesday #72 | Curated SQL
Pingback: T-SQL Tuesday #72 Summary – Data Modeling Gone Wrong | Mickey's T-SQL Ponderings