http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

Who to believe? I dare say it’s different in each situation, hence the need for a good DBA. :)

I’ve actually had problems of bad values in a database because Doctrine uses varchars and I did a whole lot of bulk operations with raw queries. Granted, it was an easy problem to fix and didn’t do any damage, but it was a bit of a pain.

Of course, it’s also been really nice to only have to update the application instead of a bunch of development and live databases.

I was wondering what the alternative was you had in mind – since I don’t think varchar is a suitable replacement in these cases?

SELECT enum_column FROM table WHERE enum_column=1; # gives you 0

SELECT enum_column FROM table WHERE enum_column=’1′; # gives you 1

I’m not saying that you should skip validation in your application code. I replied to this Brandon’s statement: “The model should be enforcing the constraints on the data types and values going into your database, not the database itself”. What I think is that DB _must_ enforce its own constraints (eg. by using FK constraints, check constraints where it would be applicable) and should not rely that application always submits consistent data.

High level checking is needed, I agree completely. However, I don’t think that “the database itself” is not the place for constraints – exactly the opposite. If you don’t enforce the constraints at the lowest possible layer, you can end up with incosinstent data because application code was e.g. buggy, the connection dropped, there was a security hole in application etc. To compare that – it’s like having a Javascript validation on a client and skipping it server-side. Would anyone recommend it?

With that in mind, enums are great if you use them for a set of values that is too small for a separate table and likely to be used too widely to be enforced in logic. Inserting new enum values in the middle may rebuild the table, and with millions of records this could pose a small problem, but the real problem would be if you were using lots of enums (they allow 65,000+ values) and rebuilding millions of records.

The truly funky thing with enums are that they are basically 1-based arrays. If you define ENUM(’0′, ’1′, ’2′), the indexes are 1,2,3, and you can SELECT using the index. The following queries show what happens if you forget quotes:

SELECT enum_column FROM table WHERE enum_column=1; # gives you 2

SELECT enum_column FROM table WHERE enum_column=’1′; # gives you 1

Also, they are sorted by this numeric index, and so that is why they do not sort by alpha.

1. MySQL 5.4/6.0 will have online capabilities, so the issue of ALTER tables taking too long will go away, an argument against something, should either be prefaced by a version #, or should stand the test of time.

2. Adding ENUM’s to the middle is indicative of a flaw in logic on the DBA/Programmers part, not the data type.

3. Sometimes, you do need the database to hande to handle constraints, foreign keys, enums etc, because you can not guarantee that the only way to access the database is going to be through your application.

4. The only reason not to use ENUM, is if you think you’ll be changing databases, and even then, you don’t switch your PDO DSN, you think through a lot of stuff before you make the change, and you should have a migration path.

As for PHP/.NET etc operating on the same database – the reality is their Model still needs to be developed anyway. If there’s duplication there, someone needs to ask why there are two languages in use creating this consequence. (Usually it’s for obvious reasons – PHP as a frontend, something else in the back – they will duplicate Models somewhat if operating on similar data).

A lot of this is why ENUMs are somewhat sensitive. They are a database construct – not a programming one. Since many of us use ORMs and design Models from a top-down perspective, they tend not to get much traction everywhere. Personally I use them only rarely – my Models will handle Enum like properties internally and just use a varchar to store the value. Enums are by no means a necessity in modelling. Their main justification would lie in performance – assuming such is measurable. Most apps won’t bother…

Note: In case nobody has noticed, when using an ORM most of this is perfectly pointless ;). If you do not use an ORM and write your own SQL, well I’m sure Enums are great at that level. Just be aware that it all depends at what level you are designing from.

First agrument (adding to middle of the set) – who would want that? It’s an enumeration, you don’t sort by it. Exemplary enumeration is CLUB, DIAMOND, HEART, SPADE (thats’s from http://en.wikipedia.org/wiki/Enumerated_type) – is diamond greater than club? You can’t tell so you shouldn’t order by it (unless you only want to show clubs next to clubs, spades next to spades etc.)

Second – “ENUM values are ordered in the order they’re added to the database”. Yes, they are. Just like AUTO_INCREMENT fields. If you used (instead of ENUMs) an additional dictionary table
and put a foreign key into the main table, it would still bite you – primary key in the dictionary table would most likely be auto incremented and you couldn’t add a value to the middle of the set or change the order without touching the main table.

If you wan’t to manipulate the order of ENUMs – you are using them wrong, it’s not the case against ENUMs.

‘ENUM values do in the database what should be done in the model’ – I’m sorry but I just dissagree, database IS a part of a model – it’s been built for exactly this purpose. You have data types, foreign keys, constraints, triggers, stored procedures, indexes – all of this is to manage persistent data. If you want to throw it out the window and try to enforce this in application layer only, you will end up writing SQL logic in PHP. Also, a single PHP application might not be the only consumer of this data – what if there is a .NET application, a Perl script or whatever which also accesses the data in your DB? You need to port the same constraints to these clients. And maintain in for the future.

My experience tells me that what could go into database layer, probably should go there. It’s compiled, optimized, it keeps the data integrity at the lowest possible level.

Of course I’m not saying you should transfer all business logic to DB or totally skip the validation in application level. For sure though, constraints must be managed by the database or you can easily end up with inconsistent data.

Such as?

There is no other reasonable alternative – that is why we have ENUM and SET in the first -beep- place.

Been using them for a number of years and I will continue to use them. This whole arguement about using them or not comes not from a database design point of view but an ORM point of view.

You can shove your ORMs where the sun ain’t going to shine if you ask me. I’m not going to use something else that would break the rules of database normalisation.

Most of the time I agree with you but this arguement I can’t.

“ENUM requires a rebuild of the table when adding a value to the middle of the set.”
I see no reason of adding an enum value to the middle of the set. Nothing prevents you from adding it to the end.

“ENUM values are ordered in the order they’re added to the database”
I don’t see any reason of ordering a table by ENUM also. ENUM is an enumeration and if you need to sort a table by it, that means, you chose a bad type for this value.

“ENUM values do in the database what should be done in the model.”
“The model should be enforcing the constraints on the data types and values going into your database, not the database itself”

I just disagree. If we take this point, we don’t need, for example, foreign keys also because this database restriction can be applied by model.

Bruce, there’s an argument to be made either way. Storing .25 in the database is proper for doing math, but the data must be manipulated in two ways in order to be displayed: it must be multiplied by 100 (to make it a whole number), and then it must be given a % symbol on the end. I think the view can handle adding the percent symbol, but the manipulation of the data should take place in the model – even if it’s just as simple as multiplying the value by 100. Still, I think we’re arguing semantics here, rather than addressing the core issue, which is that the database stores data, and the model manipulates it.