b10s,
уйти от "горизонтального" справочника к вертикальному.
Т.е. делаете к основной таблице следующую структуру (упрощенно):


авторEntity_Params
---------------------
Param_ID
Name

Params_Value
---------------------
ID
SourceTable_ID
Param_ID
Value


Недавно приходилось ровно такой процесс делать на базе, т.к. изначально разработчики "растили" таблицу вширь,
доведя размер ряда до неприличных значений.
При необходимости, можно так же внести в Entity_Params дополнительные столбцы, контролирующие тип параметров, дефолтные значения, краевые условия и т.п.

Из основных плюсов - дальнейшее увеличение количества параметров сущности совершенно не требует изменения табличной структуры, так же можно по дефолту прописать базовые неизменяемые запросы по выборке всех параметров сущности.

второй подход, так же практикуемый в нашей базе, но мне менее симпатичен - формировать таблицу расширений, с условием связи 1-1 к основной, в которую будете выносить дополнительные параметры.

Т.е. поулчается две таблицы:

авторSource
----------------
ID
Param1
Param2
..........
Param(n)


Sorce_Extension
----------------
Source_ID
Param(n+1)
Param(n+2)
..............
Param(n+k)

Параметры при этом можно разбить по смысловой нагрузке и т.п.

MasterZivb10sЗдравствуйте, уважаемые!

Имею таблицу в MySQL, где приходится некоему объекту постоянно расширять свойства и в связи с этим растет количество полей. Уже становится трудно ориентироваться и просматривать записи в этой таблице. Как быть? Есть пути оптимизации?
тут нет провода для о оптимизации пока.

Я бы уточнил "пока суммарная возможная длинна полей не превышает лимита". Для сайбеза со страницей 2к это не так много (~1962 по-моему байт), что очень быстро выедается полями по типу "Comments varchar(150)" =)

А в целом затея ТС - на мой взгляд более чем правильная - бесконечно расширять таблицу - ИМХО вред.

Leonid Kudryavtsev,

речь не про количество колонок а про общую "длинну" данных в одном ряду (исключая BLOB, которые могут в OutRow уйти)

К примеру для сайбеза ASE:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc35823.1572/doc/html/san1334282764922.html

Встречал подобные ограничения и на других СУБД.
Если данные превышают указанный лимит => будет ексепшен. Как дело обстоит на указанных вами СУБД - не могу сказать.



Подходы могут быть разные, но если какой-то атрибут встречается, к примеру, у 10% записей "городить" для всей таблицы дополнительное поле?
На вкус и цвет как говорится. Можно так же контекстно зависимые поля сделать, но сопровождение такой структуры мягко сказать не облегчается...

vadiminfoMikle83второй подход, так же практикуемый в нашей базе, но мне менее симпатичен - ....
Да уж. Симпатичное в таких подходах, скорей всего, не кажный найдет. Не кажный.

Меж тем уже неоднократно и не в одной БД (разные конторы) встречал подобные "решения", а также яростных защитников такого подхода, в большинстве случаев оперирующих всего одной парадигмой: "прямой селект, без заморочек, достаточно только джойна екстеншена".

MasterZivMikle83пропущено...
Меж тем уже неоднократно и не в одной БД (разные конторы) встречал подобные "решения", а также яростных защитников такого подхода, в большинстве случаев оперирующих всего одной парадигмой: "прямой селект, без заморочек, достаточно только джойна екстеншена".

Ничего плохого в таком подходе и правда нет, если это только для обхода физического ограничения на ширину записи.

Мне не нравится с точки зрения хранения данных подход.
К примеру, имеем ограничение в 1962 байта на страницу.
Таблица разделяется на две, условно по ~1700 байт в каждой на ряд.

Итого (без учета служебной инфы приблизительный расчет) 1962-1700 = 262 байта на каждой странице "подвисает" неиспользуемыми.
Если у нас под сотню миллионов строк 262 * 100 000 000 = 26 200 000 000 байта ~ 24.4 Гб "лишнего" места.

Хранение в вертикальном справочнике все-таки более экономно...
Можно конечно и в горизонтальных таблицах распределить поля более грамотно, но из опыта => на это слабо обращают внимание =)

Хотя оборотная сторона медали - чтение данных из "вертикальной" таблицы по одному идентификатору в общем случае может быть более "дорогостоящим" и ресурсоемким - но тут надо в каждой конкретной задаче искать "баланс".

А чаще первая таблица забивается "под завязку" по длине строки, а во вторая набивается все, что не влезло в первую.
И длина строки во второй немногим больше размера страницы / 2 - вот тут совсем забавные ситуации =)

Кот Матроскин Да ну?
в EAV у Вас на одно "смысловое" поле минимум 2 "служебных" - ID_Object, ID_Attribute. не считая пары индексов по этим полям.

Оба идентификатора int-овые => 8 байт дополнительно надо на одно "смысловое" поле.
Ранее было получено "лишние" 262 байта на каждой странице. Итого 262 / 8 = 32 идентификатора можно разместить.
Т.е. 1700 байт распределяются - под 32 "смысловых" поля. Средняя длинна "смыслового" поля при этом 53 байта.

Если каждая ваша строка содержит всего 20 "смысловых" полей по 50 байт.
Общий их объем 1000 байт - соответственно 1 страница под одну запись.

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

Тут очень упрощенно привел расчеты.
Но в реальности был пример, когда вертикальный справочник "сжал" объем данных.

Еще раз отмечу - в любом подходе требуется баланс и оценка выполняемого действия со всех возможных сторон.


P.S.: индексы вообще в расчет не беру, т.к. специфика может быть такая, что на каждое поле плоской таблицы потребуется индекс навесить... Слишком абстрактная задача - обсуждать индексы на абстрактных EAV и плоских структурах...