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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[denny]

Цитата:

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

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

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