@sprained said:
I'm porting a horrifying custom CMS to a common platform. Today's entertainment was preparing data migration. I know we see this all the time around here, but here are just a few of today's fun hair-tearing moments, courtesy of my new favorite incompetent CMS developer:
- separate tables for two different types of users, both queried on every page load
- permissions stored as a comma-separated list of paths in a TEXT field in each user table
- records with relations to user table don't use integer primary key as foreign key, but instead user's full name.
- Several user records have been renamed or removed without updating related records, leaving nearly half the records in question referencing nonexistant users
- table storing leads with redundant columns: type (always "new"), status ("new" or "sent") and category (which turned out to be an integer incremented every time a lead is sent)
- dates stored in mm/dd/yyyy format, with times as a separate column, in 12-hour format
- EXCEPT for one table that uses ISO format so that the dev could actually sort results
- (dates are always displayed exactly as formatted in the DB)
- because results can't be easily filtered by date (without convolutions that the original dev clearly didn't realize were possible) a cron job runs every night to mark yesterday's records "inactive" - and results are filtered on this column
- every SELECT is a SELECT *
- despite how very convenient PHP makes associative arrays, every database result is integer-indexed, making it impossible to track down in which files and under what circumstances a given database column is used.
I'm sure there's more in the remaining 90% of the project. In the meantime, please wish me patience.
Sprained this your incompetent co-worker. Please stop posting information about our advanced CMS. You know this CMS shall overtake all horizontal markets because of its superior:
1) Algorithmic deficiency
2) Obsfucated source code
3) Non-relational relational database tables
4) Broken test suite