Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте,

MC>Иногда в процессе работы таблицы постепенно разрастаются очень сильно, и горизонтально и вертикально. К примеру у нас order lines содержит несколько десятков столбцов. И сейчас мне вот надо очередную колонку добавить — таймстемп установки комментария, дополнительно к уже имеющемуся комментарию.

Это нормально для развивающегося проекта...

MC>Вот я и подумал — насколько это плохо когда такая таблица разрастается до десятков колонок? Имеет ли смысл делать вертикальное партицирование? Как определить когда смысл есть, а когда нет?

Если такое безобразие возникло на этапе проектирования структуры БД — то это плохо, а если "жизнь диктует" — то это почти повсеместно...

MC>Не замучаюсь ли я потом джоины писать к тому же они будут замедлять выполнение запросов. Как лучше партицировать? На 2 таблицы (90% наиболее часто используемых колонок в одну таблицу, остальные — в другую) или по смысловым группам?
MC>Приведите конкретные примеры и результаты из вашей практики?

База данных SAP R/3, например... Это что-то с чем-то! Там те же Order Lines разбиты ещё и по модулям! Одно дело модуль продаж — SD, а другое: Финансы (FI), Контроллинг (CO) и ещё куча модулей SAP-а, которые с этими самыми "строчками Заказа" связаны чисто функционально... Вообще-то в САП-е БД в большинстве случаев поставляется ВСЯ со всеми дефинициями таблиц! Так что в системе ТЫСЯЧИ таблиц находятся пустыми без единой строчки! В других системах ERP таблицы добавляются в схему, в зависимости от докупаемых и интегрируемых модулей.

Суть не в этом! Если функционально аттрибут нужен, то он должен быть!

Тут есть такое золотое эмпирическое правило Паретто "20/80": "80% всех запросов — используют только 20% данных, оставшиеся 20% запросов к БД используют 80% данных" и т.д. и т.п. Поэтому так и надо планировать. В общем случае: Таблица статических данных (неменяющихся, атрибутов, остающихся "пожизненно" в БД) -> Таблицы, связанные со статической по атрибутам, разделённым по функционалу. Связь, естественно, по первичному ключу...

Тут ещё имеет значение, какая конкретно БД используется... Чаще всего данные читаются постранично или сегментно из БД. "Позаписно" практически ни одна современная БД данные уже не считывает. Т.е. данные страницами или сегментами загружаются в кэш БД (в ОП) и уже в нём обрабатываются "позаписно". Но тут есть ещё такой момент: поля фиксированы или с переменной длиной? Это уже хоть уже и почти не имеет значения для современных серверов БД, но лучше в таблицах данные (поля, атрибуты) с фиксированной длиной располагать ближе к "левому краю" записей, т.к. указатель в памяти в кэше (а обработка данных идёт ТОЛЬКО в кэше, после загрузки страницы/сегмента/блока данных БД в ОП) может быть сразу перемещён на нужную позицию в сегменте данных, если все поля до нужного поля фиксированной длины... Но это в общем случае и не так критично с точки зрения современных "движков БД". Гораздо важнее именно делать правильную вертикальную сегментацию таблиц, ориентируюсь именно на процент (или вероятность) запросов к этим данным... Если данные редко используются, то их лучше вынести в отдельную таблицу и связать по первичному ключу.