I am at the early stages of a new project. As we are developing iteratively and relatively quickly (designing the product as we go), sometimes it can be a little bit harder to pick the "right" design for something up front. We tend to pick something and re-factor whenever necessary.
Right now I'm working on the model for user data. My approach is to have essentially 2 tables: one with essential login type data (username, created date, credentials, etc), and the other table to store Key, Value data we need associated with users.
This allows us to be very flexible in the early stages regarding what data we are storing with users. Provided we don't need complex queries on the data (which we don't yet), this allows for good scalability.
This is also a pattern I have used before.
My big question is, why is this a bad design for the long run?
The questions you should ask are:
if (Key=="something") anywhere in your code)?If you can design your application in advance for all possible keys and your application is treating them all in a specific way, you should just add appropriate columns to the "main" table and stop using the "key-value" table altogether.
If you can predict all keys but you treat some of them generically, you may keep your structure, or alternatively you may move those keys you treat specially into columns of the "main" table and leave the rest in the "key-value" table.
If you cannot predict all the possible keys (i.e. users will have ability to add their own) and even those you can are always treated in a generic way, keep the current structure.