Теория, практика...

Вот Вам практика:
Фирма работает 9 лет, все в разных таблицах, даже в нескольких базах.
Закопались так, что признали -- работать так дальше невозможно.
Пригласили меня -- сижу уже пол-года разгребаю эту кучу г... т.е. информации. А теперь о том, что занимает 90% времени:
1. Разбираюсь в структуре каждой таблицы. А структура у каждой таблички разная.
2. Из десяти однотипных, но разных таблиц заливаю данные в одну.

Прибил бы разработчиков...

Понапихали все в разные таблицы, теперь элементарное сальдо по корреспонденту посчитать не могут, потому что у них один и тот же корреспондент в трех-четырех разных таблицах сидит.

И еще один плюс насчет объединения данных в меньшем количестве таблиц.
Почему-то все считают, что фирма должна иметь в штате команду программистов, которые будут под каждый чих директора настраивать базу данных. Точнее так считают программисты, которые всегда хотят кушать и всегда готовы работать над базой -- лишь бы делом не заниматься.

А реально программист должен автоматизировать предприятие.
Сказать: работайте, я дал вам все необходимое -- и уйти!
Это в идеале конечно. Если предприятие не расширяется часто.

Нужен новый документ -- пользователь создал новый вид документа.
Нужен новый вид товара -- пользователь создал новый вид товара.
Нужен новый вид корреспондента -- пользователь создал новый вид корреспонднета.
Нужна аналитика -- добавил аналитику.
Нужен отчет -- добавил отчет.
Все сам!
Без создания новых таблиц и изменения в структуре БД.

Конечно это в идеале, но к этому иделу нужно стремиться! Нужно стремиться к автоматизации деятельности предприятия к самостоятельной работе пользователей а не завязывать на себе все потоки.
Понятно, что нужна четкая система распределия прав. Но это всегда нужно.

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

А вот теперь скажите, в какую систему проще добавить документ - в однотабличную или многотабличную?

Вам видимо проще в многотабличную... Мне наоборот. Мы оба правы.

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

Нет, не должен. Я вообще ничего не должен.
Начальник отдела создает новую папку, обзывает ее "Новый документ хитрого прихода", в свойствах папки указывает, по каким правилам должен формироваться документ, раздает права.
(Чтобы Вы правильно меня поняли -- все это он делает со своего рабочего места, с клиента, о существовании табличек он даже не подозревает.)

Может быть Вы на примере покажете, где я что-то должен.

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

Это называется "просто"? Все. Вы меня окончательно убедили, что многотабличные системы -- это ужас! :)

А ведь еще есть раздача прав, секурность и все такое :)
Обязательно! Обязательно должен быть человек, который занимается раздачей прав. Программа клиент-администратор.

TimKaНу правильно, а дальше то что происходит? что делает при этом программа, в общих чертах? Мне просто стало интересно, я ведь не спорю... К примеру создает он папку, указывает поля документа, пишет формулы проводок и нажимает ок, дальше что?

Да собственно все. На этом работа начальника отдела заканчивается. Дальше пользователь/оператор становится на эту папку, создает документ, заполняет, сохраняет. Все. Проводки есть. Можно смотреть отчеты/остатки/движение...

Видно, что знаете область, приятно с Вами иметь дело.

Хорошо быть таким начальником, у которого работа на этом заканчивается :) Зашел в программу - создал папку - пошел отдыхать :)

А программистом быть еще лучше. :) Он даже папку не создавал, он вообще ничего не делал. Он вообще в Quake играет... :)

Но я то про программу спросил :))

А что программа должна делать?
Появилась запись в т. "Папки документов", появилась запись в т. "Правила создания документов". Появились записи в т. "Права пользователя".
Я упрощаю конечно, но логика именно такая.
Начали появляться записи в т. "Документы", в т. "Содержимое документа" в т. "Дерево документов"...

А теперь представим себе что Вы программист.

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

В случае многотабличной структуры Вы не представляете структуру БД каждого предприятия, не знаете сколько там таблиц, не знаете структуры новых таблиц, вы не знаете ничего -- и чтобы обновить версию Вы объезжаете каждую фирму отдельно...
Да о каком обновлении может идти речь, если везде разные клиентские программы -- под разные структуры.

Впрочем, если Вы решаете эти проблемы -- Вы действительно хороший программист. :)

Ситуация №2
Вам предложили работу в другой фирме, где другая структура БД, на большую зарплату.

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

В случае многотабличной структуры Вам придется изучать все новые таблицы и разбираться со структурой каждой новой таблицы. И времени уйдет гораздо больше.

Впрочем мое мнение конечно необъективно... :)

2 Nikola18
См. мой пост выше № 777380.
Предположительный вариант развития Вашей базы.
Не хочу Вас обидеть, конечно если делать хорошо, то оно всегда хорошо. :)
Флаг в руках, программа клиент-администратор тоже... ;)