While I'm designing a MySQL database for a dating website, I have come with the doubt of how to store the referenced data. Currently the database has 33 tables and there are nearly 32 different fields who need to be referenced. We have to consider as well that many of these elements need to be translated.
After been reading several opinions, I have almost dismissed to use enum like:
CREATE TABLE profile (
'user_id' INT NOT NULL,
...
'relationship_status' ENUM('Single','Married') NOT NULL,
...
);
And normally I would be using a reference table like:
CREATE TABLE profile (
'user_id' INT NOT NULL,
...
'relationship_status_id' INT NOT NULL,
...
);
CREATE TABLE relationship_status (
'id' INT NOT NULL,
'name' VARCHAR(45) NOT NULL,
PRIMARY KEY ('id')
);
But it might be over-killed to create 32 tables so I'm considering to code it in PHP like this:
class RelationshipStatusLookUp{
const SINGLE = 1;
const MARRIED = 2;
public static function getLabel($status){
if($status == self::SINGLE)
return 'Single';
if($status == self::MARRIED)
return 'Married';
return false;
}
}
What do you think? Because I guess it could improve the performance of the queries and also make easier the development of the whole site.
Thanks.
Definitely a good idea to steer clear of ENUM IMHO: why ENUM is evil. Technically a lookup table would be the preferred solution although for simple values a PHP class would work. You do need to be careful of this for the same reasons as ENUM; if the values in your set grow it could become difficult to maintain. (What about "co-habiting", "divorced", "civil partnership", "widowed" etc). It also not trivial to query for lists of values using PHP classes; it's possible using reflection but not as easy as a simple MySQL SELECT. This is probably one of those cases where I wouldn't worry about performance until it becomes a problem. Use the best solution for your code/application first, then optimise if you need to.