Now I know I stated in previous posts that I'm not really excited about Meta models. But there is a place for them. They can be used sparingly here-and-there where the business area is blurred or when you need to store system configuration! Yep. A system can have many services that need to be controlled by a central database. A meta model fits the bill.
Having a database schema that is flexibable enough to handle configuration data is a wonderful thing. There are only 4-5 tables in such a model, but it saves alot of hassle when service developers ask for a new variable to be stored. Its always a slow trickle and has nothing to do with business, but rather operation needs. So when a developer asks in the 11th hour to add a new configuration field, I just add a new name value pair. The test team doesn't have to do any regression testing, because there were no changes in the schema or APIs. That is what we call a zero risk change.
Sweet! Ok. Don't over do it. When in doubt, model it out! This is just one exception to that rule ;) Keep reading below for some really cool information.