How about those NoSQL databases, huh? There’s nothing more trendy than a NoSQL database, and while they lack many of the features that make a traditional RDBMS desirable (like, um… guaranteeing writes?) , they compensate by being more scalable and easier to integrate into an application.
If reading that line doesn’t cause you to break out into hives, take a closer look at the schema.
The Content column holds a string of text, and that string of text is expected to be JSON, and they often need to filter by the content of the column, which means they have lots of queries with WHERE clauses like: WHERE Content LIKE '%"title":"Initech"%', which rank as one of the slowest possible queries you can run in SQL. The ID field in the Content column has no relationship to the autonumbered ID field that actually is on the database table. The name column sometimes contains IDs, many of the fields in the JSON content (like the img and learnItemLink fields) are actually foreign key references to other tables in the database. There’s a type column on the record, which seems to control scope, but shouldn’t be confused with the type field on the JSON document, which may or may not mean anything.
After many weeks of combing through the migration scripts, it turned out not to be a problem with the scripts at all. One of their customers started a process of simplifying their billing codes, which meant billing codes were constantly changing. Instead of only changing the codes that were… well, actually being changed, the web app which provided that interface created new records for every billing code.