Бредятина
Очень не оптимально. И структура (этот подход и в 1с), и специфическая поддержка целостности.
Очевидно, что намного удобнее иметь возможность корректировать "документы" (то есть, исправлять ошибки в совершенных операциях).

Почему не оптимально? По какому критерию?
-по минимальному объему данных,
-по скорости выполнения,
-по объему программирования,
-по понятности кода?
Документы конечно же корректируются. Но предварительно удаляются проводки относящиеся к данному документу.
Бредятина
Нужно поддерживать настоящие связи а не "обратные ссылки". То есть, нужно сначала написать нормальную СУБД (для чего и предназначен mumps), а уж потом разрабатывать приложения:)
А Вы работаете как 40 лет назад работали. Впрочем и тогда люди создавали Fileman и другие СУБД.

Что за настоящие cвязи вы предлагаете поддерживать?
Какие СУБД нормальные:
-реляционные,
-иерархические,
-объектные.
Может какие то еще есть.
Почему МАМПС не является нормальной СУБД?
40 лет назад это 70г прошлого века. Я в это время еще не программировал и если речь об СССР
то никакого МАМПСА тогда и в помине не было. И работать так как работали тогда я наврядли смогу.

Бредятина
Не лучшая, мягко говоря, идея - использовать индексы (?) для организации связей.

Очень сомнительное высказывание. Абсолютное большенство ссылок строится на основе индексов.

Блок А.Н.Возможно, я неправильно понял задачу misha_star?
В классе А есть ссылка на класс В, это поле индексируется.
По сути индекс будет "обратной связью" из класса В в класс А.
Так вроде реализуется связь "один ко многим". Или речь о чем-то другом?

В моем приложении обратных ссылок как раз нет.Нет и отношения один ко многим.
В классе А есть ссылка на класс В,а в классе В это поле индексируется.
Бредятина
Дело не в задаче misha_star. А в понимании что такое связь. И в ее реализации, основанной на таком понимании.
1) Связь не может быть свойством объекта (по Вашему класса). Дом, в котором я живу, не является моим свойством:) Таким образом, ни "ссылки", ни "обратные ссылки", ни "индексы", ни "внешние ключи" не являются правильным способом реализации связей. В частности, в РМД "внешние ключи" - это элемент ограничения целостности, а вовсе не "связи".
2) Связь - это принципиально не объект (не класс в Вашем понимании). То есть, связь многие-ко многим НЕЛЬЗЯ ПРЕДСТАВИТЬ С ПОМОЩЬЮ КЛАССА.
3) У связи нет никаких характеристик (подобных характеристикам объекта). Это формально следует из 2).
4) Связь всегда бинарная и двусторонняя. Не бывает никаких триарных и т.п. связей. Обычно за n-арные связи выдают события. А событие, наряду с сущностью - это просто разновидность объекта (по Вашему - класса), но никак не связь.
5) Все связи, независимо от их мощности, следует реализовать одинаково. Кстати, Дейт рекомендует представлять все связи с помощью отдельных отношений ("и не только потому, что связь один-ко-многим может со временем преобразоваться в связь многие-ко-многим"), но, формально, это сделать просто невозможно в РМД.

Все я потерял смысл высказывания.
Попробую объяснить как я все понимаю.

-Связь- взаимотношение объектов реального мира. Которое осознано программистом и заложено им либо в логику программ либо в структуры описаний которые потом превращаются опять же в логику программ только на уровне либо Базы данных либо языка программирования. Следовательно в любом случае это логика программы.
-Ссылка это данные которые помогают осуществлять связи. Ссылки могут быть самые различные. Для глобалов МИМПСА это либо поля данных, либо поля индексов.
Для объектов КАШЕ это это внутренние бинарные поля которые строятся КАШЕ по описанию объекта.
-Индексы, внешние ключи, поля таблиц Баз данных,внутренние бинарные поля все это реализация ссылок.
Ссылки это вспомогательный механизм для организации связей. Связь может быть осуществлена вообще без ссылок.

servit misha_shar

Возможно, Вам будет интересно почитать книгу Труб И.И.

Эта книга у меня есть. Правда никак не могу дочитать ее до конца. В се нет времени.

ser_shu
Это работает для фактографических ИС, где 99% данных заносятся в БД и даже не корректируются.

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

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

Сережа я понял. Этот механизм я обдумывал. И возможно появится случай когда он будет Эффективно работать. Тут возможно частичное применение этого метода. Например не удалять коды из классификатора, а раз в год запускать утилиту обслуживания с очисткой неиспользуемых кодов. Но это существенно зависит от срока жизни кодов.

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

Конечно в документе множество операций. А делается это для упрощения логики.
Если период закрыт то никаких корректировок этим периодом быть не может , отчеты уже сданы.
А если все таки надо корректировать то период открывается, документ сторнируется и изменяется. Но выполнить все это может только работник которому это вменено в обязанности.
Бредятина
Здесь Вы довольно серьезно заблуждаетесь. mumps вообще не СУБД, так как в ней нет никакой модели данных. И это замечательно!

А вот здесь вы заблуждаетесь. Модель данных есть и она довольно совершенная. Она иерархическая. Модель данных есть в любой организации данных даже в обыкновенном текстовом файле. Только свойства этих моделей разные.
Бредятина
mumps тогда была, и работаете Вы именно так. В общем-то так можно работать. Но это не перспективно.

Хорошо что перспективу оценивает рынок, а не вы.

Бредятина
Что же здесь сомнительного. Ведь ссылки это не связи. Стройте себе на здоровье ссылки на основе индексов, хотя что это означает понять невозможно, так как индексы обычно применяют для повышения производительности (только в классической объектной модели данных индексы можно рассматривать, как структурный элемент модели), а вовсе не для "построения ссылок". В случае реализации связей нет никаких "индексов", но на производительности это никак не сказывается.

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

Бредятина
В этом и заключается проблема:) Я не потерял смысл Ваших высказываний.

Терминология должна помогать понять смысл высказывания, а не мешать это делать.
Если применяется специальный термин то его
Бредятина
Серьезная ошибка. По такой логике объекты (а не только связи между ними) программисту достаточно осознать и заложить в логику программ:) И никакие модели данных, при таком подходе, конечно, не нужны.

Конечно это так и есть. Модели данных безусловно нужны. Это уровень абстракции который позволяет связать логику приложения со структурами данных. Модель данных для приложения в информационной системе строится всегда. И какую модель ты построишь зависит только от тебя.
Бредятина
misha_shar
Ссылка это данные которые помогают осуществлять связи. Ссылки могут быть самые различные. Для глобалов МИМПСА это либо поля данных, либо поля индексов.

Прежде, чем "осуществить связи с помощью данных" их нужно описать с помощью метаданных. Разве это не очевидно?

Совсем не очевидно. Метаданные это часть логики программы ими можно пользоваться можно вообще не пользоваться.
Метаданные существуют независимо от баз данных. Почти из любой программы можно извлечь ее структуру в виде дерева это и будут метаданные и с их помощью построить обработку.
Бредятина
misha_shar
Ссылки это вспомогательный механизм для организации связей.

Отлично! А каков ОСНОВНОЙ механизм?

ОСНОВНОЙ механизм это логика программы, базы данных и языка программирования.
Бредятина
misha_shar
Связь может быть осуществлена вообще без ссылок.

Замечательно! Как бы Вы ее осуществили вообще без ссылок?

Ну например на основе запроса пользователя.