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

MC>В общем вот как я понял ситуацию:
MC>1) Порядка 40 столбцов в таблице это нормально (понятно что с нормализацией все нормально, т.е. все столбцы реально к примеру описывают order line, т.е. в тему) и переживать не стоит
MC>2) Можно вынести в отдельную таблицу только если этот столбец используется очень редко (как мне кажется заморачиваться с разделением на таблицы в таком случае нужно только если столбец используется очень редко, к примеру в 1% запросов)

MC>Правильно я понимаю?

Правильно понимаешь! Вообще, не бойся нарушать запреты! Но! Если в чём-то сомневаешься, действуй "по-классике"... Стандартные схемы действуют всегда в общем случае!

MC>Следующие вопросы к тем кто на практике занимается вертикальным партицированием:
MC>1) Замеряли ли вы реальную разницу в скорости работы? Какие результаты?
MC>2) Какие минусы вы встретили после этого

1. Не замерял. Было пару случаев, когда просто знал, что это улучшит структуру таблицы и скорость запросов.
2. Ну какие какие... Дополнительные затраты времени на перекройку таблиц и ещё на администрирование...

MC>И еще давайте разберем конкретный пример.
MC>Допустим есть таблица order_lines, в ней порядка 40 столбцов. Теперь потребовалось приделать комментарий к order line. Добавил поле Comment. Через год потребовалось узнать время в которое был поставлен комментарий, чтобы к примеру можно было посмотреть все проставленные комментарии за сегодня. Собираюсь добавить столбец TSComments типа TIMESTAMP.
MC>Вы бы сделали так же?

Я бы сделал... Но сначала бы BLOB-ы или текстовые длинные поля вынес бы вообще сразу в отдельную таблицу! Даже в отдельный tablespace (Oracle), а если вообще всё так печально, то и в отдельный filegroup, куда-нибудь "в отстой" с другой схемой RAID-а... Но поять же! Всё зависит от объёма данных и от типа и видов запросов к БД! Может, в твоём случае, это вообще не существенно! Перекроить-то схему — это не долго вообще-то! Да даже запросы не так уж долго... Ну, разумеется, если был создан уровень "представлений" (view) или "stored procedures"...

MC>Хотя возможно можно вынести Comments + TSComment (+ завтра может понадобиться указывать пользователя который проставил комментарий) в отедльную таблицу. Но действительно ли от этого будет толк. Вдруг этим я только распложу кучу таблиц и потом буду дополнительно тратить время на джоины, который к тому же будут немного замедлять запрос?

Будет, будет! Все комменты, БЛОБы и прочие нерегулярные объекты выноси из главной таблицы сразу! Всё равно в большинстве реализаций они вообще никак не участвуют в SQL-запросах! Ну, кроме, полнотекстового поиска... А это есть в запросах? Выноси! Даже не задумывайся! И куда подальше от реального дискового пространства, где хранятся статические и оперативные таблицы! Ну, извини, это ещё и от конкретной базы зависит! Вот я знаяю, например, где там есть "тонкие места" в Оракле, Майкрософте и в МайСикуеле... Ой! Так сразу и не ответишь! Есть там заморочки СВОИ! Надо смотреть... Так сразу и не ответишь...

MC>Вот так вот и терзаюсь в незнании как лучше и правильнее

Абстаргируйся от самих таблиц! Делай больше запросов через "представления"! Вообще-то, я уже давно пользую такую модель (паттерн?), чтоб толко через "представления" (view) к базам обращаться... Поверь! Самое большие потери производительности не превышали 2%... И в алгоритме самой задачи больше "собак рылось"! Оптимизаторы современных БД достатчоно хорошо "представления" акцептируют... Но опять же! О какой базе мы говорим? У каждой есть свои тонкости и заморочки... Так просто универсально совет и не дашь! Ну, есть правила общие для всех реляционных БД... Есть теория... Но нужно СМОТРЕТЬ!

Честно говоря, нет никакой гарантии, что "вертикальное партицирование" как-то улучшит или ухудшит твои приложения, работающие с БД... Смотри сам! Может дело и не в структуре БД? Может дело в самих "аппликациях"?