Dangers of using MYSQL...What are they?

Question

Dangers of using MYSQL...What are they?

Viewing 2 posts - 46 through 46 (of 46 total)

You must be logged in to reply to this topic. Login to reply

Flammon-942859 Grasshopper Points: 14 More actions · Answer 1

jgrubb (11/19/2008)
Many MySQL Users were of the opinion that "good" application programmers didn't make mistakes, so you could rely on them to "do the right thing" with the data".
(pause for the laughter to die down)

Not quite. The opinion was that if it slowed down the database engine and it could be done at the programming level, leave it out.

For a central, general purpose data store, integrity, reliability, and recoverability are Crucial.

Absolutely and MySQL gives you all of those. You seem to be implying that it doesn't. Please explain.

jgrubb SSCrazy Points: 2542 More actions · Answer 2

Flammon (11/19/2008)
jgrubb (11/19/2008)
Many MySQL Users were of the opinion that "good" application programmers didn't make mistakes, so you could rely on them to "do the right thing" with the data".
(pause for the laughter to die down)
Not quite. The opinion was that if it slowed down the database engine and it could be done at the programming level, leave it out.
For a central, general purpose data store, integrity, reliability, and recoverability are Crucial.
Absolutely and MySQL gives you all of those. You seem to be implying that it doesn't. Please explain.

I stand by of those statements. As to "slowing down the db engine", Absolutely moving those things into the DB have an effect. One could argue about the magnitude as compared to doing it code, but the important piece is that any validation you rely on external (to the db) code to perform is not guaranteed to execute if you are not using that code. Imports, integrations with other applications, multi-purposing data MUST understand and MUST follow the same rules or you get inconsistencies. Something as simple as a Not Null constraint can be the difference between meaningful information and a bunch of junk.

You can choose to not do the validation in the DB, but until V5 MySQL didn't give you many tools to enforce integrity, and in certain instances, they still fall a little short. They are "late" in the design, and it shows.

As to the integrity etc. I said it's gotten significantly better. Good enough for lots of things. If I were putting together a website, especially on *nix, it'll be on the short list. If I'm doing something on a tight budget, I might choose that. If I were going to build a high volume OLTP app, I'd push for something else.

If you want to get into specifics, It offers you a choice of storage engines. The fastest is ISAM, which doesn't support FK's, is not ACID, and only has table level locking. They have a nifty looking clustered filesystem, until you realize it has no FK support and only Read Committed. If you understand the limitations, these are not a problem, but you DO NEED to program with these in mind. If you need to install on a shared server, these can be a problem.