Naug
Если я правильно понял, что Вы хотите, второй вариант представляется мне предпочтительным.

Если я правильно понимаю, Вы ставите задачу сохранения в базе однажды сформированных отчетов. Каждый отчет состоит из N выборок данных. Давайте рассмотрим, что есть в каждом из случаев.

1) Все в одной таблице.

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

(-) Выборки намного тяжелее. Если в индексах хранятся null-ы - получится прорва сложных, составных индексов, каждый из которых лишь на несколько процентов индексирует реально нужные данные, а все остальное - забито информацией, которая никогда и ни при каких условиях не будет выбираться по этому индексу. Статистика идет лесом - если в выборке 1 селективен атрибут "фирма", а в выборке 2 селективен атрибут "контрагент" - в результирующей таблице они запросто окажутся равно бесполезны.

(-) Довольно быстро окажется, что есть три-четыре атрибута с похожим смыслом (типа firm1_id, firm2_id, firm3_id), поскольку они нужны для выборки типа X. При этом по историческим причинам выборка Y использует в значении "фирма куда" firm1_id, в то время как выборка Z использует firm1_id в значении "фирма откуда", а добавленной позже "фирма куда" не остается ничего, как использовать firm2_id. В целом - полный бардак. Чтобы сразу назвать их firm_from_id, firm_to_id итп потребуется зверская убежденность, поскольку будет хор голосов "у нас же есть поле фирма - давайте использовать его для другой похожей операции. Зачем делать еще одно поле?".

(-) Задачи сопровождения на такой таблице будет решать максимально тяжело.

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

(+) Все в одной таблице. Правда, не понимаю, чем это плюс. Мировой запас таблиц жестко ограничен?

2) Разные таблицы. Собственно, все наоборот.

(-) Тяжелее решается задача "отчет состоит из гибкой конфигурации разделов". Если секции в отчете одного типа могут идти в разном порядке и/или количестве - потребуется согласование "номера секции" между таблицами.

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

(+) Структура данных нормализована во всеми вытекающими преимуществами в плане простоты и удобства разработки и сопровождения. Достаточно представить себе документацию по "одной большой таблице" - "если значение поля "тип отчета" равно двенадцати, в поле "код фирмы" содержится код фирмы отправителя. Если значение поля "тип отчета" равно тринадцати..."

(+) Проще и легче будет делать над-отчетную аналитику, например, сравнить данные по одному типу за разные периоды.

NaugМеня смущает то что во втором варианте потребуется добавить не одну колонку, а одну таблицу - соответственно все запросы тут же усложнятся (использованием join или доп аргументами where).
Вот этого не понял.

Каждый запрос идет к одному разделу. Отчет состоит из серии разделов, то есть из серии запросов, каждый к своему разделу. Наоборот, SQL упрощается, поскольку не требуется дополнительно каждый раз фильтровать большую таблицу по "нужны данные N-го типа раздела".

Naug
Конечнно по идее они должны генериться автоматически, но всё же - что лучше - select с 6 полями из одной таблицы или select с 6 join-ами? И если мне нужно добавить дефолтовое значение - в новой таблице придётся сначала копировать список всех первичных ключей?
Не понял. Если Вы имеете в виду "держать N атрибутов в одной таблице" либо "держать N тех же атрибутов в виде N отдельных таблиц" - первое куда лучше. Вопрос в том, что имхо и то, и другое - не очень-то хорошо.

Naug
Есть например одна большаааая табличка с данными из баланса. 200 атрибутов. Имеет смысл делать 200 таблиц, или одну с 200-ми атрибутами?
Одну.

Вопрос в том, что на другую таблицу, с проводками, надо использовать другую отчетную таблицу, а не ту же, что и "балансовые разделы отчетов".

NaugСпаибо насчёт информации о скорости работы - я раньше не сталкивался с такими объёмами данных чтобы структура принципиально влияла на производительность, но всё таки что лучше - 200 маленьких запросов на insert, или один большой. (Конечно при условии что этот большой вообще выполним.
Я очень затрудняюсь представить себе условия, при которых двести будут лучше. Если замерить варианты - почти уверен, что "двести маленьких" окажется в среднем раз в сто хуже.

Naug
Сейчас запрос одного раздела для определённой организации и даты , в первом варианте выглядит так -

Не понял. Я бы предположил, что так делается запрос "всего-всего-всего" для организации X на дату Y - всех строк всех разделов, примерно так.

Naug
Однако если нужно отобрать одно поле для отчёта по нескольким другим (например определённую характеристику для всех компаний со статусом "хороший клиент" выглядеть это в первом варианте будет так
Стоп. Я окончательно перестал Вас понимать. В таблицах лежат сохраненные данные отчетов? Или что?

В общем, сформулируйте подробнее постановку задачи.

NaugВ таблицах лежат сохранённые данные отчётов. Дилема в следующем:
1)Иметь одну таблицу с одним первичным ключём (с множеством колонок -по числу разделов в отчёте - я вовсе не складываю все данные в одну ячейку.
Следует ли понимать так, что в одном поле одной строки будет лежать весь "раздел"? Тогда да, одна таблица будет наиболее удобна.

Я исходил из модели, что раздел - это некая выборка, то есть N полей на K строк.