Slashdot Mirror

Does MariaDB still do shit like this?

http://sql-info.de/mysql/gotch...

That gotcha list is from a decade ago. It explicitly states they weren't tested against MySQL 5.

Does MariaDB still do shit like this?

http://sql-info.de/mysql/gotch...

MySQL has always been a way to serve unimportant data at high speed. Great if you're serving up fuzzy matches to people who are doing a Google search and have no preconceptions about what they will get back in response to a search, or organizing a web forum visited by millions where if you lose someones comment, you really don't care. If you're dealing with data where accuracy, reliability and predictability is important, though, it was a ticking time bomb waiting to blow up in your face.

Has that changed at all? After all the years he spent trying to promote his DB into spaces it didn't belong, telling people that things like data integrity didn't matter and should be handled at the application layer, I have zero trust for the man, but perhaps things have improved?

There's a comparable list of PostGreSQL gotchas from the same source.

Only if "comparable" is code for "far shorter and less severe, with a greater percentage having been fixed in current versions".

The post is basically a troll for a video. The video is based on an old list of MySQL 4.x gotchas, many of which were fixed in the 5.x series. Most of them involve things like the semantics of NULL in special cases, truncation of indexed strings with trailing spaces, and similar stuff that an application shouldn't be relying on. There's a comparable list of PostGreSQL gotchas from the same source.

MySQL has political problems, because Oracle owns it and would prefer users buy their commercial products. The future of the free version is uncertain. The problems in the video aren't the ones to worry about.

The post is basically a troll for a video. The video is based on an old list of MySQL 4.x gotchas, many of which were fixed in the 5.x series. Most of them involve things like the semantics of NULL in special cases, truncation of indexed strings with trailing spaces, and similar stuff that an application shouldn't be relying on. There's a comparable list of PostGreSQL gotchas from the same source.

MySQL has political problems, because Oracle owns it and would prefer users buy their commercial products. The future of the free version is uncertain. The problems in the video aren't the ones to worry about.

Lots of people such, but it is just hard to trust your data to MySQL. Just a moment ago I posted a link above to this video which illustrates it:

http://www.youtube.com/watch?v=1PoFIohBSM4

The person narrating that video sounds so much like Mr. Garrison I couldn't make it past the first minute. However the video is based largely off the info found here:

http://sql-info.de/mysql/gotchas.html

Please do not tell people to use mysql_escape_string. That function is broken and does not escape proper.

Also, just because you need to dynamically construct a string doesn't prevent you from using prepared statements. Just need to make sure user input is always passed to the database through parameters.

That being said - don't use MySQL in the first place; handling customer data and especially billing information (OP says customer site) in MySQL is just asking for trouble. ( http://sql-info.de/mysql/gotchas.html - note this was written for 4.0 as it says, but a lot of them are still very much a problem today).

You claim to have been doing this for 23 years and think MySQL does a nice job?
http://sql-info.de/mysql/gotchas.html

Read that, it might save your job... (Oh and most of those gotchas are still very much a problem in 5.0).

MySQL is the Visual Basic of databases - clumsy and of poor quality, used most strongly by people who don't know any better. I would be delighted to see MySQL fail as a project and have its mindshare go to projects that are superior, like PostgreSQL.

Agreed. There's an excellent list of MySQL "gotchas" that illustrates just how bad it is - http://sql-info.de/en/mysql/gotchas.html
The list only applies to <5.0 versions - anyone know a similar list for >=5.0 ?

still, I'd prefer not to handle mysql structural data, as it mangles text removing spaces

What version of MySQL are you talking about? This page claims that MySQL 5.0.3 and later preserve trailing spaces in VARCHAR columns, and all versions preserve trailing spaces in TEXT columns.

Now, for the citation needed folks: http://sql-info.de/mysql/gotchas.html

From the linked page: "Update: Apparently this behaviour will be corrected in the planned 5.0 release", and it was.

What have you been smoking ? Lots and lots of people have complained about MySQL for a long time,
e.g.: http://sql-info.de/mysql/gotchas.html

Here is someone who likes mysql trying to explain why automagically inserting default values for
columns that are supposed to have the constraint NOT NULL is a good idea versus the insert failing:
http://www.databasejournal.com/features/mysql/arti cle.php/3519116

The only thing mysql has going for it is that PHP integrates so nicely with it and for many web apps
thats great but for anything else there are far better choices.

This page has a list of MySQL gotchas

http://sql-info.de/mysql/gotchas.html

Some of my favorite are things where MyQL accepts values it shouldn't and it doesn't throw an error. For example you can insert a 0 into a date field, 30000000000 into an in column (it will just ignore the higher order bits.

MySQL is OK for quick and dirty, but it will always be dirty. If you want MySQL to be decent:

1) Set it up with InnoDB and make that the default table type. MyISAM should only be used for data warehouse tpye applications where you are doing a lot of IO and its OK for the DB to be down for hours while you recover your corrupted MyISAM tables.
2) Set the strict sql mode in the my.cnf. I don't remember exactly what the parameter name is, but you want MyQL to throw an error if you throw stupid values at it. Otherwise it will accept wacky values and you'll end up debugging it later.
3) Set the default character set to UTF-8 if you can. This can be a bear but its worth it to be able to handle foreign characters.
4) Avoid the fancy "features" if you can. The old features still have unresolved bugs and it isn't going to get any better with more and more storage engines going in.
5) Monitor the performance constantly and be prepared to partition your data. Scale out isn't always as easy as it sounds.

And its hard for mods to tell the difference between a troll and a genuinely stupid poster sometimes. Claiming that transactions are seldom needed is probably enough for people to think "nobody can really be that stupid" and thus decide you're a troll.

http://sql-info.de/mysql/gotchas.html

Most of that list is data integrity problems. Its not FUD, its fact.

Oracle's Acquisition of InnoDB: What does it mean?
Recently Oracle acquired a small Finnish software company, Innobase. This has attracted far more attention than transactions of this size usually do, and for good reason: this directly affects MySQL, which styles itself as "the world's most popular open source database".

What is InnoDB and why is it important?
MySQL has the ability to use different database "storage engines" (modular code which can be "plugged in") in the database server to actually do the nitty-gritty work of storing and retrieving data in the underlying tables.

The most widely used engine is "MyISAM", which is also the default engine. It is fast, but is missing many features which are considered a standard part of "enterprise level" database software, such as transactions amd foreign key support. This means MyISAM does not provide much in the way of facilities for maintaining data integrity, which is essential for all but the most trivial of database applications.

However, if MySQL is to establish itself as a serious competitor in the enterprise database market- not just as a nifty backend for web-based forum systems and the like - it needs a "heavyweight" database engine which can guarantee data integrity and is reliable enough to, say, run an accounting system on.

This is where InnoDB comes in. InnoDB is a transaction-safe (ACID compliant) storage engine with foreign key support along with commit, rollback, and crash recovery capabilities.

InnoDB is a product of Innobase Oy, a Finnish company now owned by Oracle. InnoDB was first released as a part of MySQL in 2001. MySQL has a licensing agreement with Innobase which enables it to provide the InnoDB code under a commericial license to paying customers, alongside the distribution as a GPL (open source and free as in beer) product.

I guess this is another thing to add to the MySQL gotchas page. Of course, in a decent database engine, like PostgreSQL, if you alter a column data type then the indexes are updated to reflect this.

Once again, I really don't think you took the article in the intended context. Here are the author's two major issues with both PHP and MySQL.

1. Bug ridden (by this I am including both misfeatures as well as actual bugs).
2. They encourage bad habits.

So, he was including issues beyond just the acknowledged bugs. MYSQL in particular has a lot of non-standard SQL quirks that create real problems for any serious development work. This site lists the major ones prior to 5.0. And PHP has numerous issues of comparable severity, like magic quotes and it's historic lack of a consistent interface for prepared queries.

I suppose the author devoted his attention to misfeatures, as opposed to more straight forward bugs. However, I think that he made his intended focus clear at the beginning. And I don't consider the second point to be hyperbole at all. I think he substantiated the first point enough to use it as a foundation for the second. Although, I will admit that my professional experience makes me significantly inclined to agree with both points. So perhaps I am taking certain background knowledge and technical details for granted.

The fact that PHP and MySQL are the most deployed tools for web development is a rather sorry situation, given the deep shortcomings of both tools.

See these articles about the many PHP warts:

Experiences of Using PHP in Large Websites

Why PHP sucks

The PHP Ghetto

You will be happier with a more mature and complete dynamic language like Python, or even (gasp ;-) ) Ruby.

Similarly, see these other articles about the many MySQL warts:

MySQL Hate

MySQL Gotchas

Compare the last one with the one for PostgreSQL:

PostgreSQL Gotchas

Finally, an in-depth comparison between MySQL and PostgreSQL on Slashdot itself:

Comparing MySQL and PostgreSQL 2

Finally, recall that both MySQL's transactional backends are now controlled by Oracle:

Oracle Acquires Sleepycat

Avoid both PHP and MySQL as much as you can, I say. There's better stuff out there.

The fact that PHP and MySQL are the most deployed tools for web development is a rather sorry situation, given the deep shortcomings of both tools.

See these articles about the many PHP warts:

Experiences of Using PHP in Large Websites

Why PHP sucks

The PHP Ghetto

You will be happier with a more mature and complete dynamic language like Python, or even (gasp ;-) ) Ruby.

Similarly, see these other articles about the many MySQL warts:

MySQL Hate

MySQL Gotchas

Compare the last one with the one for PostgreSQL:

PostgreSQL Gotchas

Finally, an in-depth comparison between MySQL and PostgreSQL on Slashdot itself:

Comparing MySQL and PostgreSQL 2

Finally, recall that both MySQL's transactional backends are now controlled by Oracle:

Oracle Acquires Sleepycat

Avoid both PHP and MySQL as much as you can, I say. There's better stuff out there.

Says here that the marketing VP quoted in TFA, Paola Lubet, used to work for Oracle.

Now I wouldn't want to read anything into that, I'm guessing there's a lot of rotation between database companies, and it's a private company held by a bevvy of investors, so Larry Ellision presumably won't be able to drop it in his shopping basket when he pops out for some milk. On the other hand the investors sound like venture capitalists (I may be wrong, corporate finance is not my field) who might be interested in any short-term returns on their investment that a large, cash-rich company could offer.

Is data corruption on working hardware a real problem for MySQL?

Yes, it is.

http://sql-info.de/mysql/gotchas.html

Just use Google to find MySQL Gotchas to see all sorts of wierd behavior of MySQL (NULL sometimes not really being NULL for example?). Of course, other systems have strange things, too.

This alone is enough to run screaming from MySQL, although it is for MySQL 4 (not 5, which is the latest). There are tons of things just on this MySQL Gotchas page that strike fear and panic into the hearts of database programmers who know anything about *real* databases and what they are used for.

Just use Google to find MySQL Gotchas to see all sorts of wierd behavior of MySQL (NULL sometimes not really being NULL for example?). Of course, other systems have strange things, too.

This alone is enough to run screaming from MySQL, although it is for MySQL 4 (not 5, which is the latest). There are tons of things just on this MySQL Gotchas page that strike fear and panic into the hearts of database programmers who know anything about *real* databases and what they are used for.

SqlServer is a dog from a performance standpoint. If I was given the choice of Oracle versus SqlServer, I would pay the extra $35K. Seriously....

I spent six weeks optimizing a bunch of SQL stuff for processing once. We supported both MSSQL and Oracle. The MSSQL I finished in about three days. The Oracle work took the rest of the time. The MSSQL processing ran in 1/4 of the time the Oracle did on the same hardware and equivalent schema. MSSQL's SQL optimizer is *so* much better than Oracle's it isn't even funny. You can get high performance out of Oracle but you have to really pay attention to what you are doing. For example, if you have an index on (x,y), if you query WHERE y= and x=, it won't use the index. MSSQL had no problem rearranging the WHERE clause, for example. Additionally, with Oracle to get the best performance, you have to deal with physical disk layout and write your SQL accordingly. You can do that on MSSQL but you can still get 90% or better of the best just by letting the thing do it all for you.

Of course, if I was given any choice, I would probably pick MySQL. MySQL is light, fast, forgiving, and pretty scalable.

Yeah, we use MySQL a bit now and it's fine if you just want glorified text files by default. If you want transactions and the like, you have to do non-default things, which is OK I guess. However, most people who use MySQL don't think transactions are ever needed (mostly because they don't understand what they are and why they are needed). Plus, there are lots of places where your "forgiving" statement seems to mean that MySQL can give back data to you that you didn't think it would (as in... when is NULL not a NULL? see MySQL Gotchas for some interesting behaviors that are... fast and forgiving, I guess).

http://www.linuxquestions.org/questions/showthread .php?p=2131445#post2131445 might shed some light.

And then of course there's http://sql-info.de/mysql/gotchas.html

Easy setup and administration?
Yeah, postgres is really hard to setup.
apt-get install postgresql
sudo su - postgres
createuser noob
^D
createdb its_just_not_that_tricky

Or you could just download and install one of the gui tools if command lines scare you.

Handy SQL extensions?
Oh, you mean like how there aren't any procedural languages supported? You know, the ones that would obviate the need for hackish extensions that only half solve a given problem? Or perhaps you're talking about all the dumb foot cannons that MySQL AB thought was clever?

Enterprise features for those who want them and not for those who don't?
Like... replication? Oh wait, that's a postgres feature that MySQL hasn't even dreamed of supporting. MySQL only just recently figured out what a transaction is a couple of years ago. They still haven't figured out NULL. I'm not sure exactly what enterprise features you're refering to, but then I don't think you are either since MySQL hasn't got any. Which is probably why nobody uses MySQL in enterprise environments whereas Postgres a non-trivial chunk of the internet.

MySQL is fine for things where data integrity is not an absolute necessity, but where it is, for example the db's that store a multinational corporation's complete financial data, you couldn't trust MySQL. I understand MySQL 5 has made improvements in data integrity, but I don't know to what extent. MySQL developed their database for speed and convenience, which is why webdevs like it, and succeeded in creating a very fast db, but sacrificed correctness and integrity for it.

MySQL is fine for things where data integrity is not an absolute necessity, but where it is, for example the db's that store a multinational corporation's complete financial data, you couldn't trust MySQL. I understand MySQL 5 has made improvements in data integrity, but I don't know to what extent. MySQL developed their database for speed and convenience, which is why webdevs like it, and succeeded in creating a very fast db, but sacrificed correctness and integrity for it.

MySQL is fine for things where data integrity is not an absolute necessity, but where it is, for example the db's that store a multinational corporation's complete financial data, you couldn't trust MySQL. I understand MySQL 5 has made improvements in data integrity, but I don't know to what extent. MySQL developed their database for speed and convenience, which is why webdevs like it, and succeeded in creating a very fast db, but sacrificed correctness and integrity for it.

Most of this stuff is common knowledge, but here are a few links I was able to dig up:

Wikipedia Criticisms (with sources)

Comprehensive list of MySQL "gotchas"

Interesting Blog Entry

Google should be able to provide more info on MySQL's problems. It's getting better, but I still trust my data to PostgreSQL.

The reason for this problem is that the query planner did not use an index on a bigint column when the 123 literal in the query was an int literal, so id did an sequential scan instead of an index scan. But this problem is well-known with well-known workarounds, and fixed since 8.0. Another workaround is using select * from tbl where id = 123::bigint For a full list of postgresql (and mysql) gotchas, see http://sql-info.de/

Correctness covers a lot of things. You could even put transactions under that category (correctness of data at query time), for example.

Also, if you were worried about free (as in beer) databases, Microsoft (note that I didn't use M$ like a child) has offered a free RDBMS for a long time (Access, which was replaced by MSDE, which has been replaced by SQL Server Express). So, while MySQL *is* a free alternative to SQL Server, I would argue that your product selection to meet your criteria was flawed (as you didn't actually consider various free alternatives).

And yes, for some queries, MySQL is documented as being able to return incorrect values (as another poster has said). In fact, you should check out this site to see what all else some versions of MySQL do for you that are.... unexpected.

Here's a list of another MySQL gotchas: http://sql-info.de/mysql/gotchas.html

From my experience as a developer using MySQL on several projects, MySQL has a looong way to go. It not only lacks a ton of features, but also lacks data integrity checks, stability, and data validation (amongst other things). E.g. I've once managed to insert (by mistake, of course) two rows in a table with same PKs. The result? MySQL didn't warned me about it, inserted the data instead. Every SELECT on that table killed the server in the background, causing automatic mysqld restart.

Being open source/free software doesn't mean that we have to be less forgiving to the glitches mysql has. Look at postgresql - it's doing fine, supporting every DB feature I can imagine and is rock-solid stable. I haven't seen lame excuses like "stored procedures coming really REALLY soon" on their site recently.

I wouldn't recommend mysql for anything other than address-book type of things... and all the mysql fanboys can go screw themselves - it's not a good database, period.

Any word on when they are planning to fix this? With this careless disregard for data integrity, it's hard for me to take MySQL seriously.

It would be cool if someone knowledgeable could check the old MySQL Gotchas list and see how many have been fixed in 5.0. My hope is, nearly all of them.

If you're creating a BLOG or web forum, foreign keys and transaction management aren't vital in the way they are for financial applications.

It is so easy (see the MySQL Gotchas site) to accidentally lose transactional and foreign key support even if you installed InnoDB libraries that it is pretty dangerous to depend on the notion that any of the "data integrity" functionality is actually in place.

And the classic sorts of MySQL(tm) applications were written for version 3.23, so it is common to be unable to use InnoDB on the longstanding web apps.

At OSCON, the MySQL AB guys seemed pretty uncomfortable with the notion that the new versions had to support all this data integrity stuff. This buyout can let them head back to what they are comfortable supporting.

K.I.S.S. is what MySQL has always been about

K.I.S.S. implies - at least in my book - correctness, something MySQL has never been about until maybe recently.

Check here for starters: http://sql-info.de/mysql/gotchas.html

Yes, I know it says "Note to Slashdot readers: this page deals with issues related to MySQL 4.1 and earlier, not 5.0". But how is this different from Microsoft saying "Windows now really is getting secure, promise!"

I wouldn't feel comfortable using a product whose developers made glaring mistakes or just didn't care in the past, no matter if they "got it together" now.

And it still doesn't invalidate the point of the GP that MySQL is just recently catching up and now you ask how it is behind the times. There are simply other databases that did it right the first time and have earned their trust.

So these RDBMSs provide tools - triggers, stored procedures, a multitude of locking mechanisms, DRI (Declaritive Referential Integrity) and so on. With a well built database:

• You *can't* insert duplicate data
• You *never* modify data behind a users back (e.g. remove trailing spaces on varchar)
• You *never* break a foreign key, leaving dangling data
• You can perform all maintenance while the DB is live
• and so on...

'Industrial Strength' RDBMSs are about predicability and reliability. Speed is important, correctness is essential. MySQL aint there yet. Oracle, MSSQL, Postgres, Sybase, to name a few of my favourites, are.

Let the flames fly :-)

So these RDBMSs provide tools - triggers, stored procedures, a multitude of locking mechanisms, DRI (Declaritive Referential Integrity) and so on. With a well built database:

• You *can't* insert duplicate data
• You *never* modify data behind a users back (e.g. remove trailing spaces on varchar)
• You *never* break a foreign key, leaving dangling data
• You can perform all maintenance while the DB is live
• and so on...

'Industrial Strength' RDBMSs are about predicability and reliability. Speed is important, correctness is essential. MySQL aint there yet. Oracle, MSSQL, Postgres, Sybase, to name a few of my favourites, are.

Let the flames fly :-)

So these RDBMSs provide tools - triggers, stored procedures, a multitude of locking mechanisms, DRI (Declaritive Referential Integrity) and so on. With a well built database:

• You *can't* insert duplicate data
• You *never* modify data behind a users back (e.g. remove trailing spaces on varchar)
• You *never* break a foreign key, leaving dangling data
• You can perform all maintenance while the DB is live
• and so on...

'Industrial Strength' RDBMSs are about predicability and reliability. Speed is important, correctness is essential. MySQL aint there yet. Oracle, MSSQL, Postgres, Sybase, to name a few of my favourites, are.

Let the flames fly :-)

If you're serious about your data, then try this out:

CREATE TABLE t(t tinyint);
INSERT INTO t VALUES(300);
SELECT * FROM t;

See also http://sql-info.de/mysql/gotchas.html

Hey...we have to talk about these gotchas: http://sql-info.de/mysql/gotchas.html. Remember, this is the land of freedom.

They have done very little about these MySQL gotchas! They should have eliminated most of them first. You can still read them here: http://sql-info.de/mysql/gotchas.html.

I always figured Oracle to be a badly assorted mass of a lot of files preferrably scattered around on a lot of disks. I think the architecture is a mess and that installation, administration and tuning is like a root canal while you get all four wisdom teeth extracted at the same time without narcosis. But...

If you have a look at this list of MySQL idiosyncrasies you will see why MySQL is simply unusable in an enterprise environment, or even in an environment that relies on the validity of your database transactions.

That doesn't mean that MySQL doesn't have a legit place, but it's certainly not in the billing environment of a major Telco, or in any billing environment for that matter.

The more I learn about MySQL (from the perspective of someone who was initially gung-ho about PostgreSQL), the more I realised the shortcomings of MySQL weren't really shortcomings. They were misunderstandings.

It's hard not to misunderstand MySQL's bizarre handling of NULL/NOT NULL or their lovely silent truncation.

MySQL Gotchas

A critical responsiblity of the dbms is to ensure data integrity independently, that is: the dbms should have the native capability to never have to rely on and/or trust the accessing client to sanitize or validate input data. This means that it is more desirable for a query to fail than for the dbms to try and guess intention of or worse, "correct" the query if the query will result in a constraint violation. There should be no so-called "undefined" behaviors. If an outcome of a query won't be deterministic, it should fail (excluding things using an auxillary prng for obvious reasons), or barring that, at least emitting a warning. The speed of the query should always secondary to the resulting integrity of the data.

Several MySQL gotchas have been documented on stable versions. Many of these are egregious pitfalls plaguing this dbms. Some of these are just plain violations of SQL (i.e. playing with the definition of NULL or column types behaviors like VARCHAR), to outright altering input.

Finally, the reliability is atrocious. Since there is no "repair table" option for innodb, I have to fetch a backup copy of the db because it gets corrupted so easily. The concept of supporting atomic transactions is made irrelevant if the physical portion of the engine still gets trashed in a way requiring major manual intervention.

I see, you're a SQL purist. Not that there's anything wrong with that. It's just that I come at things from a bit of a different perspective.

I'm not an SQL purist, I'm a data integrity purist. Did you read the "Gotchas" site I linked to? MySQL silently inserted an empty value for a NOT NULL field. There are an alarming number of cases where data is truncated silently, zeros are entered silently, and NULL fields leads to weird assumptions on MySQL's part--all silently. I like my databases to let me know when they're making assumptions or doing anything automatically so I can respond to it in code.

Here's another article--MySQL Oddities.

I do have one follow up question for you. You mention that you don't like having to get the PK after an insert into an auto_increment field, but I still didn't see any reason why this system doesn't work. Do you have an example where it's necessary to get the PK before the insert? Or is this just a matter of preference?

Not only do I like to be able to associate user-uploaded files with content they may be editing but haven't yet published and submitted to the database, but MySQL's auto_increment leads to situations where 0 equals 1. MySQL just ignores what you give it sometimes without warning and does its own thing. I can't trust that, not for what I do.

Now, sure, I could walk around it all and conform my code to compensate, but I think it's the job of the database to be protecting its integrity, not me.

But yet the issues raised at http://sql-info.de/postgresql/postgres-gotchas.htm l are irrelevant to your usage of Postgresql, right?

* MySQL: o Native Windows version o Large base of compatible applications and software o Easy to get running * PostgreSQL: o Fast yet with an incredible feature set o Excellent data integrity (vital for serious database work!) o Very, very stable and reliable from http://sql-info.de/mysql/vs/mysql-versus-postgresq l.html

http://www.huihoo.com/postgresql/mysql-vs-pgsql.ht ml

Changes/corrections since that study was made:

PostgreSQL now natively supports BLOBs directly in tables (bytea type) as opposed to using oid references.

PostgreSQL has always had "better than row level" locking, Multi-Version Concurrency Control.

PostgreSQL has added Java and Ruby to its list of stored procedure languages.

----------------

Now, here's the caveat. MySQL 5.0 is still marked as a "development release (use this for previewing and testing new features)" so I didn't include it in the above. If we include MySQL 5.0, we must also include PostgreSQL 8.1, currently in beta.

MySQL 5.0 adds views, stored procedures, triggers, cursors, the bit data type, up to 65K varchar fields, two new storage engines (federated and archive), and a strict mode.

PostgreSQL 8.1 adds two-phase commits, a role system, shared row level locks using SELECT, and many speed improvements.

The strict mode in MySQL is most exciting to me. I always bought the argument that MySQL could have fewer features in exchange for greater speed. But there is no excuse (in my opinon of course) to accept random strings into numeric fields and other such contrivances (MySQL gotchas). Data integrity in a database should not be an optional feature.