You should see the one here. An old flat file database monstrosity from the 80s, imported into oracle, complete with all of the duplicated data. It's the most non relational, relational database ever.
Well, this is used now by about 4000 clients. So you be the judge. There is so many indexes, and spaghetti, just to make sure every possible "relationship" is accounted for. Amazing it works at all.
"Badly". At least once a week someone managed to overwrite a change another client had just made. When I left, they were running a cron to copy it every minute as a "quick restore" when it happened.
Yeah, first real job had the customer database as a VB frontend onto an Access file shared over {whatever Win95 was using in 1996-97}. After a few snafus, the CS / Sales people learned that they had to single-task with the database.
I have 177 tables, 764 stored procedures and 44 joins.
Every single table has either a uniqid() or a UUID() which isn't the primary key (they all have incrementing integer keys) but is 'joined' on in code.
When he needs to 'join' he used coalesce() on selects.
Referential integrity doesn't exist.
Oh and the cherry on the shit sandwhich, we have four seperate systems that talk to this database written in 3 different languages (Java (Android scanners), C# (Factory scanners) and PHP (the main system).
So there is no way to accurately know which SP's are used by what without grepping the entire codebase looking for call <foo>.
The PHP is written badly in the old PHP pure procedural style running on an outdated version of PHP/Debian/MySQL.
Basically if you took the absolute worst approach to everything this would be the end result.