Most databases these days are RDBMS types. An RDBMS is all about identifying linkages between Pieces of Data. Usually using a unique identifier known as a primary key. They can often get to be really big with lots of interconnections in the various tables. They also have one important feature. They may tend to force you to make assumptions about the data. You are retrieving. A Table expects certain kinds of data in certain kinds of formats. If you need to add a kind of data you have to either create a new table with new linkages or you have to modify the table in question. Either one means more work for you. If your database is too discriminatory it might even be impossible without massive rewriting of your code. This is great if you want to limit and enforce data relationships. But what if you want freeform relationships. What if you want to be able to modify and change the way your data relates on the fly? What if you app needs non-discriminatory data types? An RDBMS may not be the way to go. A sufficiently complex Database with lots of data relationships can be impossible to modify at times. You might be faced with a choice, add a new set of tables and relationships (thus contributing to the growing complexity and the problem) or create a whole new database and export, then import your data into the new database with any translating you might need along the way. Metadata to the rescue!!! All pieces of information have metadata associated. Simply put, Metadata describes a piece of information. A checking accounts balance might have the following associated Metadata: It's an integer, It's currency, It's rounded off to two decimal points when displayed, It's referring to account 55341 at bank of somewheresville, you wish it were a higher number. All of this Metadata puts the number into context for you. In fact that is the other way of describing metadata, (The context your information inhabits.) For some applications, information context is the name of the game. Those applications can benefit from a Metadata based information design. Storing your music collection, for instance, is one such application. You choose what music to listen too based off of your mood. Maybe you want something soothing, so you choose soothing classical music. Soothing and classical are metadata about the song title. If you music database allows for on the fly metadata about the song titles then classifying and finding your music is potentially much easier. At it's most basic a Metadata based database design is extremely simple in structure. All that is required is two "tables". One "table" only needs two columns. An indentifier and a peice of information. The other one needs needs three columns = "metadata type column, an information link, and the metadata content. MetaData Design Graph The real power of this is what it allows you to do in your code. Adding Metadata is dead simple. You can organize and sort you data in any fashion you want to. You can update, change, or expand your data description on the fly with changes to the database. A whole world of possibilities begins to expand before you. Not every application can benefit from that kind of flexibility though. Certain Applications need the strict control over relationships that a traditional RDBMS design gives. Accounting applications for instance rely on strictly defined relationships. But if your application can benefit from this then it's a huge boon to your development and design to use."