There's a lot of material out there about Key/Value or EAV builds. They CAN be useful if you're sure your data will be homogeneous across all the values. They also under-optimize BADLY. For example... if you're looking for a series of associated attributes to an entity, do you want to pull back 7 rows (or 5 rows) instead of a single row? Answer: Most of the time, no.
In general, EAVs cause a lot more problems than they fix. Sure, the schema is more modular, but you've blown optimization to pieces, aggregations are a royal PITA (see IsNumeric() and WHERE clause for a simple example), and generally working with them is enough to cause permanent DB professionals to pull their hair out.
The schema can change later. Use column names (instead of *) in all your procs and use some common sense when expecting changes and you'll be fine, and the DB will love you for it.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA