> From: (Halász Sándor) h...@tbbs.net > >>>>> 2014/10/29 20:56 +0100, Zbigniew >>>> > if instead of textual labels I'll use SMALLINT as simple integer "code" for > each different "label" (and in my program a translation table)? > <<<<<<<< > This, in effect, is ENUM...
Well, not really! With INTEGERs, your referential integrity is external to MySQL, and has to be managed. > ... and maybe is useful if the set of dates is well determined... I was not suggesting it for dates. The OP appeared to have a well-defined set of strings in a VARCHAR field — THAT is what I suggested ENUMs for! > There is a design cost in using ENUM: If you find that your first set of > dates is too small, later, with ALTER TABLE, you have to change the type. Again, the suggestion for ENUM was to replace a constrained set of VARCHARs, and yet, you raise a valid point. What is the update frequency of those VARCHARs? If you're adding them often — or if you need to occasionally change their value — I'd use another table with a reference. If they're immutable and new ones are not added often, there's no "design cost" at all to using ENUMs. I'd argue there's a higher maintenance cost to NOT using them! :::: Jan Steinman, EcoReality Co-op :::: -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
