Люди, подкиньте идею, если не трудно...
Есть в БД запись (документ, проводка, номенклатура и т.п.). Для этой записи определены ряд обязательных параметров. Со временем требуется набор этих параметров расширять... Как лучше реализовать?
1. Все параметры в одной таблице с основной записью.
2. Отдельная таблица для основных записей и отдельная для всех параметров.
3. Отдельная таблица для основных записей плюс таблица с параметрами, где для каждого значения параметра есть отдельная строка вида (запись_ID, параметр_ID, значение)...
4. Свой вариант...
Подскажите, плиз...

Megabyte, пока тоже пользуюсь третьим вариантом... Но уже возникают трудности...
Дело в том, что количество параметров постоянно растет... Таким образо количество записей в таблице параметров на порядок, а то и больше, чем в таблице основных записей... Это начинает сказываться на производительности....

Сергей Васкецов TORTЭто начинает сказываться на производительности....
Можно сравнить "бонусы" хранения конкретного параметра "методом 1" и "методом 3". Если первый метод становится лучше, и не слишком много в системе надо менять (например, отчеты), то вполне можно перенести его в основную таблицу, если уж приспичило.

По теме - обычно 3-м методом делаю только такие параметры, которые пользователь (в смысле, администратор клиента) может произвольно настраивать по своему усмотрению. Если значения участвуют в бизнес-логике, то 3-й метод не использую.

Все параметры настраиваются исключительно админитратором сервера. Только их набор постоянно увеличивается (особенности работы организации, так сказать:) )... Поэтому на стадии проектирования было решено использовать все-таки 3 метод...

Прошло 2 года с момента внедрения и вот теперь видно, что количество записей с такими вот параметрами весьма велико.... Это и усложняет работу...

Чендлер, хм... Думаем над этим вариантом... Интересует доступ к информации в таком случае... Нужно тестировать...

Страдалецъ, ну это мой третий вариант я так понимаю...

Все зависит от механизма работы СУБД с XML-данными... Но мне также кажется, что это метод не самый лучший...

MySQLCraft
1. Параметр - есть некое расширенное свойство объекта, причем не для всех объектов оно может быть определено.
2. В поле "Значение параметра" теоретически может содержаться любая информация... Поэтому предполагается, что это строка....
3. Основная запись - это набор полей необходимый и обязательный для всех объектов, которые хранятся в данной таблице.
4. Не понял... По-конкретнее вопрос, если можно...
5. .....

MySQLCraft

1) В данной постановке, является ли "отношение" расширенным свойством = параметром?
Для каких объектов параметры не могут быть определены?
2) Строка годится, как вариант.
3) Почему набор полей основной таблицы является необходимым и обязательным? Какие конкретно поля обязательны и чем они отличаются от параметров? Приведите пример реализации, ибо в предельном случае основная запись содержит только одно поле ID, оно же Primary Key.
4) Имеется ли отношение между записями в основной таблице или это линейный список?
5) Если отношение имеется, то почему оно содержится в основной таблице, чем оно особенно? см.п.1

И еще вопрос.
Мы говорим об объектах. Что понимается под объектом? Класс или экземпляр класса?
Как в данных таблицах различаются эти сущности?

Объекты в моем случае - это экземпляры классов... По Вашей терминологии "различных классов, имеющих в конечном счете общего родителя". Есть набор атрибутов(параметров, в моей терминологии "расширенных параметров"), набор которых уникален в пределах класса. Более того, он изменяем в дальнейшем... Плюс, на мой взгляд важное дополнение, изменяем относительно просто и часто....
В основной записи содержаться "линейные" записи.

drev, чаще запрос к группе объектов + выбор 2-3 параметров для этих объектов... Тут проблема, кмк, в том, что при увеличении кол-ва типов параметров, размер таблицы с ними растет очень быстро.... Вот в этом для меня проблема этого подхода...