оптимальное кол-во полей в таблице

[SHiSHok]

Существуют-ли рекомендации относительно количества полей в таблице (Ax3), может на размер записи?
Вопрос возник при добалении очередного поля в параметры клиента CustTable.
Т.е. возможен следующий подход: создать отдельную связанную таблицу (например CustTableAdv) и доп. поля/параметры справочника уже прописывать там. Я вижу и плюс и минус такого подхода:
плюс: при добавлении достаточно большого количества полей стандартный функционал не будет "гонять" все эти дополнительные поля по коду (понятно что технический прогресс решает большинство проблем при написании неоптимального кода, тем не менее хочу оптимально)
минус: Дробление информации и необходимость повторного поиска записи при необходимости получения параметра из другой таблицы (безспорно что многое зависит от задачи и необходимости иметь единовременный доступ к множеству полей таблицы).

Ваше мнение.

Цитата:

Сообщение от SHiSHok

...
Т.е. возможен следующий подход: создать отдельную связанную таблицу (например CustTableAdv) и доп. поля/параметры справочника уже прописывать там. ..

Ваше мнение.

Месье знает толк в извращениях

ЗЫ: Усложнение жизни путем создания доп. таблицы не особая проблема, но по моему мнению без веской причины такая доп. таблица особого смысла не имеет. А + и - вроде бы описали достаточно точно.

[glibs]

Смотря как вы к этим данным будете доступаться.

Вот тут стоит почитать, если ожидаются большие объемы данных.

dynamicsmatters: Performance and InventDim

Также обратите внимание, что CustTable кэшируется. Думаю, что с принципом работы механизма кэширования вы знакомы.

[denny]

Подобный подход уже использовался моими коллегами и был признан нежизнеспособным. Одна из проблем навскидку: при необходимости отобразить поля из разных таблиц на одном гриде вам вне всяких сомнений потребуется inner join. Представим себе, что для старых записей в первой таблице (custTable) записей в новой таблице нет - соответственно, в гриде вы их просто не увидите. Для того, чтобы их все-таки увидеть, необходимо писать отдельный job, создающий такие записи... В общем, долгая песня.

[gl00mie]

Цитата:

Сообщение от denny

Одна из проблем навскидку: при необходимости отобразить поля из разных таблиц на одном гриде вам вне всяких сомнений потребуется inner join. Представим себе, что для старых записей в первой таблице (custTable) записей в новой таблице нет - соответственно, в гриде вы их просто не увидите. Для того, чтобы их все-таки увидеть, необходимо писать отдельный job, создающий такие записи... В общем, долгая песня.

Интересно, как же это при таких «сложностях» у людей не развалился, к примеру, номенклатурный справочник?..

Цитата:

Сообщение от SHiSHok

Существуют-ли рекомендации относительно количества полей в таблице (Ax3), может на размер записи?

Существуют определенные объективные технические ограничения:

• максимальное количество полей в таблице (вроде 256)
• максимальная длина строки SQL-запроса, которую может переварить СУБД, и за пределы которой можно вылезти, выбирая все поля из такой таблицы сложным запросом с join'ами;
• работа СУБД с таблицами, содержащими разного рода BLOB'ы (тот же Oracle их обрабатывает по одной записи, что на ряде операций приводит к трудновообразимым тормозам);

В остальном же, мне кажется, нужно руководствоваться тем, как наболее адекватно отразить сущности предметной области. Подумайте, являются ли свойства, данные по которым вы хотите хранить в таблице клиентов, атрибутами сущности "клиент", возможна ли ситуация, когда они будут иметь уникальные значения для каждого клиента. Может быть, часть свойств является атрибутами какой-то другой сущности, и следует хранить их в отдельной таблице, с которой у таблицы клиентов будет связь N:1.

Цитата:

Сообщение от SHiSHok

Вопрос возник при добалении очередного поля в параметры клиента CustTable.
Т.е. возможен следующий подход: создать отдельную связанную таблицу (например CustTableAdv) и доп. поля/параметры справочника уже прописывать там. Я вижу и плюс и минус такого подхода:
плюс: при добавлении достаточно большого количества полей стандартный функционал не будет "гонять" все эти дополнительные поля по коду (понятно что технический прогресс решает большинство проблем при написании неоптимального кода, тем не менее хочу оптимально)

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

Цитата:

Сообщение от SHiSHok

минус: Дробление информации и необходимость повторного поиска записи при необходимости получения параметра из другой таблицы (безспорно что многое зависит от задачи и необходимости иметь единовременный доступ к множеству полей таблицы).

Все же мне кажется, тут надо больше думать не об удобстве выборки данных из реляционной БД, а о более адекватном отражении в этой БД сущностей предметной области

[leva]

В целом согласен с gl00mie.

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

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

[SHiSHok]

Немного по ограничениям MSSQL2k:
Length of a string containing SQL statements (batch size) = 65,536 * Network packet size1
Columns per base table = 1,024
Bytes per row = 8,060

Философия обьектной модели это замечательно, но зачастую приходится бороться за производительность системы (особенно с течением времени). Так вот одной из целей проекта я всегда ставлю выбор такого решения, которое в дальнейшем не приведет (минимально отразится) к ухудшению производительности приложения. А вот тут хорошобы цифры реальные иметь для анализа (опятьже с цифрами уже можно будет взвесить что важнее: красота обьектной модели или производительность, а может оно и совпадет ;-) ).

[gl00mie]

Цитата:

Сообщение от SHiSHok

Философия обьектной модели это замечательно, но зачастую приходится бороться за производительность системы (особенно с течением времени). Так вот одной из целей проекта я всегда ставлю выбор такого решения, которое в дальнейшем не приведет (минимально отразится) к ухудшению производительности приложения. А вот тут хорошобы цифры реальные иметь для анализа

Ну какие тут могут быть конкретные цифры? Если у вас используется для той же таблицы клиентов штатный режим кэширования - это один расклад, если вы его меняли (скажем, боролись с рассинхронизацией кэшей нескольких АОСов) - это другой расклад, если вы используете тот же Oracle и настроили в рабочей базе, чтобы вся таблица CustTable всегда деражалась в памяти, - это третий расклад...
Понятно, что при работе с СУБД нужно думать о производительности, но если посмотреть на то, что в куче мест стандартного приложения методы дергают записи из таблиц целиком, чтобы взять одно поле, то такие попытки улучшить производительность начинают выглядеть как сизифов труд... Мне кажется, надо все же "плясать от" предметной области, а оптимизацией заниматься уже после - по факту. Потому что если изначально реализовать "неадекватную" структуру данных, то никакие такие мелкие хитрости и оптимизации не спасут. Ну сколько у вас записей в таблице клиентов, сотня, тысяча?.. Посмотрите на тот же номенклатурный справочник, сколько в него полей понапихано, а ведь там бывают десятки тысяч записей - и ничего, работает система как-то...

[leva]

Опять же обеими руками поддержу gl00mie.

Правило 5 Стиля программирования на C, выражающий точку зрения на философию UNIX:
"Данные преобладают. При правильной и хорошо организованной структуре данных, алгоритмы становятся очевидными. Структуры данных, а не алгоритмы, являются центральной частью в программировании."

[denny]

Цитата:

Сообщение от gl00mie

Интересно, как же это при таких «сложностях» у людей не развалился, к примеру, номенклатурный справочник?..

Никто не говорит о принципиальной невозможности. Но работать с тем же номенклатурным справочником как с четырьмя (пятью!) отдельными записями в разных таблицах, согласитесь, неудобно. Ради чистоты замысла (ах, у нас повторяющиеся поля в закупке, хранении и продаже!) и примерно 30 полей (извините, аксапты под рукой нет) регулярно получаем вопросы новичков про импорт InventTable и пустой справочник номенклатур после этого, отдельную процедуру в check and fix для исправления данного безобразия, пункт в FAQ. Как раз в данном случае игра на мой взгляд свеч не стоила.