Это (imho) одна из классических проблем проектирования баз данных.Назовите это «атрибут крип», возможно, когда вы начнете, всегда будет еще один атрибут или свойство для добавления.Ключевое решение заключается в том, храните ли вы данные в базе данных, используя базовые инструменты, предоставляемые базой данных (таблицы и столбцы) для структурирования и форматирования данных, или сохраняете данные каким-либо другим способом (пары XML и имя / значение)будучи наиболее распространенными альтернативами).Проще говоря, если вы храните данные в форме, отличной от той, которая поддерживается системой СУБД, то вы теряете способность системы СУБД управлять этими данными, работать с ними и работать с ними.Это не представляет большой проблемы, если вам нужно только сохранить их как «данные BLOB-объекта» (сбросить все данные, выкачать все это), но как только вы начнете искать, сортировать или фильтровать по этим данным, он может получитьочень некрасиво очень быстро.
С учетом сказанного у меня есть твердое мнение о парах имя / значение и XML, но, увы, ни одно из них не является положительным.Если вам действительно необходимо хранить данные таким образом, и да, это может быть полностью обоснованным решением для бизнеса / дизайна, то я бы посоветовал долго и усердно смотреть на как данные, которые нужно сохранить в базе данных,быть использованы и доступны в будущем.Взвесьте все «за» и «против» каждой методологии в свете того, как она будет использоваться, и выберите тот, который проще всего управлять и поддерживать.(Не выбирайте тот, который проще всего реализовать, вы будете поддерживать его гораздо дольше, чем будете его писать.)
(Это долго, но эссе "RLH" является классическим примером запуска пар «имя-значение» amok.)
(О, и если вы используете его, посмотрите на опцию «Разреженные столбцы» в SQL Server 2008. Не похоже, чтовам нужно, но вы никогда не знаете.)