Senya_L, не понял, чем тебе первый вариант не нравится?
По подробнее, pls

ЗЫ я бы его выбрал (только может быть чем-нибудь дополнил - от специфики)

Уточняю решение по варианту №1:

1) Сущность <Атрибуты> - собственно справочник, содержит поля:
Атрибут_ID - Суррогатный ключ
Атрибут_NAME - Название аттрибута
Атрибут_DEFAULT - Значение аттрибута по-умолчанию

Уникальный индекс (ключ) по Атрибут_ID
Уникальный индекс по Атрибут_NAME

особенности: при добавлении аттрибута в справочник - значение данного аттрибута автоматически добавляется всем аттрубутам карточек со значением по-умолчанию (Предлагаю физически в базу - так проще потом запросы делать).
При удалении - удалять записи из аттрибутов карточек.

2) Сущность <Карточки> - содержит экземпляры карточек, поля:
Карточка_ID - Суррогатный ключ
... - технические поля, например дата создания карточки

Уникальный индекс (ключ) по Карточка_ID

3) Сущность <Аттрибуты_карточек> - Список аттрибутов карточек. Поля:
Аттрибут_карточки_ID - Суррогатный ключ
Карточка_ID - Карточка
Атрибут_ID - Аттрибут
Значение - Строковое значение аттрибута

Уникальный индекс (ключ) по Аттрибут_карточки_ID
Уникальный индекс (ключ) по (Карточка_ID, Атрибут_ID)
Индекс по Карточка_ID
Индекс по Атрибут_ID
еще можно по (Атрибут_ID, Значение) и/или (Атрибут_ID, To_Date(Значение)) - для оракла, в MS сами напишите и т.д.

Больше всего объем будут занимать именно эти индексы. Они же примут на себя основную нагрузку в обеспечении производительности.

----------
Запрос с критериями:
- в принципе можно по другому написать, что производительнее у Вас - решать Вам.

Теоретически, можно три значения аттрибута хранить - как строку, число и дату, а использовать то, что нада, остальное - NULL. Потеряем в объеме, в производительности должны выиграть (наверно).

Senya_LИ не то чтобы не нравиться, но смущает то, что
авторКартотека может содержать более 1 000 000 записей.
Это не много.
Вот для аттрибутов карточек, если видов аттрибутов 50, то получаем уже 50 000 000 записей.

Еще один вариант:
две сущности, первая - карточка с аттрибутами, вторая - метаданные аттрибутов.

Нужно добавить аттрибут - расширьте таблицу (первую) и добавьте данные во вторую.
Первая - снужными типами данных и т.д.
Вторая таблица нужна только для сопоставления человеческих названий с названиями полей в БД (первой таблице), описания их типов - для построения нормального клиента.

А что?
СУБД зачем нужна?! Правильно, чтобы управлять. Вот и пусть управляет

Senya_LKOT MATPOCKuHЕще один вариант:
две сущности, первая - карточка с аттрибутами, вторая - метаданные аттрибутов.А как это будет выглядеть с CREATE TABLE? Не CREATE TABLE, а ALTER TABLE ADD COLUMN

Senya_LKrebДля разных карт разные полностью атрибуты не будут это не нужно. Справочник один.И ради чего тогда, простите, трахаете моск?! Одна таблица для карточек, возможно кое-какие справочные таблицы. Чего мудрить-то? Вы это все затеяли, чтобы при "Если 1000 000 карточек, ввели новый параметр, то автоматом в CardAttribute появится 1 000 000 записей."? Вообще-то есть дефолтные поля у таблиц на этот случай, есть также нуллябливые поля.


KOT MATPOCKuH, Я же не зря спрашивал афтора про переменный состав атрибутов ;)Дак я-то понял, просто ответа от автора не было какое-то время, вот и предлогал...

KrebKOT MATPOCKuH,
Поясните, пожалуйста как быть, если значения параметров например int или Datetime. В таблице значений они текстовые,
а искать используя Cast( as ) - не Гуд.
СУБД PosgreSQL 8.3. Идею использовать индексы адаптированные к типу скрытому в varchar не уловил.

и/или (Атрибут_ID, To_Date(Значение)) - для оракла, в MS сами напишите и т.д.

С уважениемКак вариант предлогалось следующее: в таблице значений аттрибутов карточек хранить не одно поле значений типа текст, а три поля: текст, дата, число. Что именно используется для конкретного параметра - описать в справочнике аттрибутов. А в запросах - вы же сами знаете, что возраст - это число, а дата рождения - это дата. Соответствующие поля и используете, когда пишите SELECT. В "универсальных" запросах - через справочник получаете тип, по нему - используете соответствующее поле.

Kreb... СУБД PosgreSQL 8.3....
А чего:
Модератор: Тема перенесена из форума "Microsoft SQL Server".
?????

Senya_LKOT MATPOCKuHSenya_LKOT MATPOCKuHЕще один вариант:
две сущности, первая - карточка с аттрибутами, вторая - метаданные аттрибутов.А как это будет выглядеть с CREATE TABLE? Не CREATE TABLE, а ALTER TABLE ADD COLUMNЯ имел ввиду DDL модели EAV. А то, что здесь нужна одна таблица - автор молчит, хоть ты развей мои сомнения. Автор-то забил.Не понял, какие сомнения развеить? Что нужно автору - ему и выбирать, мы только предлагаем варианты

Senya_L
А что, посчитать некошерно?
Из-за такой ерундовины так ломать нормальную структуру с одной таблицей?
Сползаю под стул... :)

Держись!!!!

Да, некошерно из-за объемов данных и универсальности вопроса.
Если бы карточек было 100-200 - было бы без разницы, но когда начинаем считать милионы...
Я в одном из своих предложений показывал, что по полю "значение" таблицы значений аттрибутов карточек нужен индекс. Иначе, для любого запроса с ограничением значений аттрибутов будем иметь FULL TABLE SCAN, т.е. полный просмотр большой таблицы.
В оракле, например, можно сделать одно текстовое поле, но сделать индексы:
- по самому, полю
- по функциям преобразования значения поля к числу, дате и др..
Тогда SELECT * From T Where to_number(val) = 10, при наличии индекса на to_number(val) будет выполняться по индексу очень быстро. (Кстати, как следствие такого решения для упращения запросов я предлгал прописывать значениями по-умолчанию значение нового аттрибута во всех карточках)

В других СУБД чаще всего такое невозможно, а т.к. автор задал вопрос на этот форум, то нужно универсальное решение, не зависящее от СУБД.