Users is a bit of a core table in most applications. If they were using the relational database as it should be used there would be references to the user table elsewhere in the database.

If you tried to delete the table, it would fail stating that a deletion would violate the constraints assuming you didn't have deletions cascade automatically (which would be equally bad).

On the other hand (and it probably happened here) there will be one table with all sorts of data bolted on.

So say you want a user to have multiple pieces of armor (following the spirit of this post). You should have an armor table and a user to armor many to many table. But instead you just add an Armor column to the user record and create a new user record (with a the same username for example but with a different unique artificial key) with the new piece of armor in the armor column. Then to retrieve it you just select armor where username = whatever and iterate through the list. Adds and deletions are just as easy. So, why not? Well, duplication of data, for one thing. And no referential integrity protection for another. Delete a username and everything is deleted. Forget a where clause and you are sunk.

Ah I see.. I misunderstood the first time around. I thought you meant to store the user table in a flat file. Thank you for the explanation. That reminds me, I need to convert to Innodb one of these days.