If you work with databases, you must look at the data.
In some shops, to understand the system, you look everywhere, except at the data model. It’s the “meaningless model”.
Do you use the VIN, or the license plate to identify a car in the DMVs system? The choice has huge implications!
There are a lot of systems using Cobol out there these days. Even though the systems were built on top of Oracle databases from the start!
Duplicate data. How can I count the ways?
Another bizarre database design is to split up a table vertically. In other words, to have duplicate tables!
MUCK: Massively Unified Code-Key, Generic Three Table Data Models cause lots of problems: Awful performance, Pivots, Require multiple inline views, data type Issues, really complex inserts, increased people time, cost, and create a Cobol system. Just say no!
There was a functional dependency, violating 2NF. The first field, determined the second field. This of course should have been moved into another table, but it wasn’t.
The database “design” was a binary tree! The nodes were actually being used for both storage, and indexing! In order to find any data, you had to write a routine to traverse the tree. That is, instead of using standard tables, and standard SQL Select statements, with Where clauses to filter the rows.
There were circular references in the foreign keys. You couldn’t insert into first table, because it needed to find the row (via the foreign key) in the second table. But when you went to insert into the second table, you couldn’t insert there, because it needed to find a row in the first table.