Why do you insist on making the HUMAN interface match the DATABASE schema?
Just put the ACTUAL year of the song into a SMALLINT column (SMALLINT can go up to 32767).
Then, if the user select's "80s", you just do
... WHERE songYear BETWEEN 1980 AND 1989 ...
If you make the field songYear
and index, that will be every bit as fast as using an artificial decades numbering system. Plus it gives you full flexibility, later, to show the full year the song was published/first appeared, if you want to. (And you probably will, I would bet.)
And why why why would you be concerned about data size?
Your (pardon me, but it's true) silly scheme of using "" or NULL will save you, at most, *FOUR* bytes per song. If you had a million songs in your database, that's only 4 Megabytes. *NOISE* on a modern disk drive, where we typically measure database size in GIGABYTES. You queries will be *MUCH* slower using your scheme than if you just used a BOOLEAN NOT NULL field (which is the same as a TINYINT NOT NULL field, by the by). Plus, if you needed you could index the field(s) for performance. Something you can't do with your scheme. But the primary reason for doing this is for ease of maintenance. Somebody can come along and do a DB dump and instantly see the purpose and values of all your data.
Personally, with MySQL I don't worry about database size until I start getting up over 10 to 20 GIGAbytes. (And even then, if there is a good reason for the size, I don't worry about it.) It's not like you have to store this data *ON* the mobile devices. It's all stored on the server, so who cares how big it gets, within reason? *PERFORMANCE* is much more important, in almost all cases. And if I can trade off disk space for performance, I'll do it almost every time.