On the CodeForest site there's a recent tutorial that offers a different option for those dealing with an application that has the possibility for rapid change in its database structure - a key/value table in a standard relational database (no, not NoSQL).

Key/value approach in database design could come in handy when we need to store some arbitrary data about another table. For example, we have a users table that holds our user data. Everything is working fine, but some day our client decides that he wants to collect 2 telephone numbers, sex of the user, date of birth... If we try to predefine all the potential wishes of the customer in our table, it would be awkward and our table would grow horizontally beyond reason.

He compares the traditional "users" table with each column a defined type of data against a key/value table where each record holds both the value and a key relating to its contents. While this technique can be flexible, it can also be abused if it gets out of control. Bill Karwin warns in the comments about it and links to two resources on its use.