91 items are buggy as there is a sorta of shift in the columns, before those items even crashed everyone in sight of who used them. (note there are probably countless ones in addition to these 91 bugged for other reasons, like items with a script which is missing etc)
As I wrote earlier: consider the cruft in the database as a test case for how ironclad the server code is.
Data errors will inevitably be reintroduced, be it via server bugs, via somebody with an erroneous SQL UPDATE in Phpmyadmin, a bug in the web frontend, or someobdy entering wrong data in the web frontend. As has been written by others, if the server chokes on invalid data, you have two bugs: one in the data, one in the code that cannot handle it.
Possible solutions:
1) Use Postgresql and add CHECK and FOREIGN KEY constraints. That would take care of the vast majority of wrong data.
2) Have a database access layer and have it check the constraints on the C++ side.
Both approaches would be lots of work, but a wipe would be a non-solution to the database problems IMNSHO.
Either solution would have a very positive side effect though: coders would have a by-definition precise and complete documentation of what they can write to the database and what they cannot. That's better than those always-slightly-outdated specification documents or that always-slightly-incomplete hearsay.