Programmer_OrtodoxГлянул по этой ссылке на эту Арбинаду, ну не прикольнула она меня ни чем! Опять лобовое решение, опять "этот", тот же перечень полей, надо 10 аналитик,значит вдолбим в таблицу при создании эти 10 полей. А ещели я к примеру хочу, чтобы в одной проводке была 1 аналитика, а в соседней проводке 21, а через одну, - 121 !? И чтобы по каждой из них уровней было от 2 и по "самое не балуйся"? Пусть уж коллективная творческая мысль дальше ввысь стремится! А то не интересно как то..
Я понимаю, что с первого взгляда смотрится не так красиво, тогда как всем хочется "большой и чистой любви" :)
Но эта схема является заточенной под реляционнку (горизонтальное хранение аналитик) и опробована на больших массивах данных, будучи при этом оптимизирована. Вертикальное же хранение дает более высокие накладные расходы и сложные запросы.

strizhЯ у себя в системе храню аналитики проводки в массиве заданного размера.
Это нереляционная структура, поддерживаемая небольшим количеством СУБД, преимущества которой перед горизонтальным хранением не вполне очевидны.

Сахават ЮсифовГлубоко начхать - какая эта структура. Главное, что бы работала быстро и правильно и имела бы возможность масштабироваться.
Очевидно, что если вы ставите целью масштабирование, то не должны "глубоко начхать" ;)

strizhПреимущество одно. Можно делать 'group by db_analitic', 'where db_analitic = ...', 'where db_analitic is null' и прочее не задумываясь особо, а сколько ж максимально аналитик (какой размер массива) сделали при создании базы и сколько из них сейчас определены в проводке.
При вертикальном хранении число аналитик также неограничено.
Горизонтальная же используется в качестве опимизации.

Используя массивы вы не сможете декларировать целостность (каждый элемент ссылается на объект-аналитический разрез). Ее придется программировать триггерами.

strizhА при горизонтальном хранении целостность можно гарантировать, если только поля кодов аналитик назначать конкретным аналитическим справочникам. 'Лобовое решение', как сказал Programmer_Ortodox, - в каждой проводке по дебету и кредиту делать поля типа id_contragent, id_people, id_section, id_production, id_warehouse, id_income ... Тоже мрачно получается :(
Достаточно объявить внешний ключ на таблицу - общего предка всех классов, используемых в качестве аналитик.