БредятинаEmery Да, мы имеем набор таблиц, связи между которыми являются метаинформацией.
Вы, надеюсь, имеете в виду описание связей. Так описание таблиц тоже является метаинформацией. Что-то Вы здесь путаете:)
Да, вольность речи :) . Метаинформация по описанию таблиц есть в базе, а по описанию связей нет. Эту связь можно увидеть только в самом коде.

БредятинаEmery Эта метаинформация может быть представлена схемами данных, которых я много рисовал на этапе проектировании своей системы (в 1С77).
Так в этих "схемах данных" есть ведь и "таблицы", а не только "связи" между ними:)
Есть, ну и что? Разве трудно понять связи между таблицами «один ко многим» и «многие к одному»?

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

Бредятина1) Термины "первичная таблица данных" и "вторичная таблица данных" оказались бесполезными для модели данных (они не поддерживаются в Вашей модели). Это было очевидно изначально. Например, у Персоны могут быть характеристики Фамилия, Имя, Адрес проживания (ссылка на дом, от которого автоматически строится полный адрес, или как это у Вас называется), Адрес прописки (аналогично), Дата рождения и т.п. Очевидно, что это и "таблица первичных данных" и "таблица вторичных данных" (ведь в ней есть "отношение между объектами":)
Поддерживаются не поддерживаются – не в этом вопрос. Просто без понимания этих различий в таблицах трудно построить оптимальную структуру БД. Не хотите, не применяйте эти термины, я свою идеологию никому не навязываю. Я еще не говорил об этом, но таблица сотрудников это очень сложный «справочник». Он имеет множество подчиненных справочников, большое количество полей массу таблиц, на которые ссылается. Но это все первичные таблицы, так как одно определение ссылается на другое определение, или одно определение имеет несколько других подчиненных определений. Например, сотрудник может иметь несколько назначений, подразделений, графиков работы и т.п. одновременно. Но «отношения» между ними еще никакого нет, только иерархическая структура «определений».

«Отношения» для сотрудников (в данном случае с временны’ми промежутками рабочего времени) начинаются в справочнике (таблице) документов «Первичные табеля». Часть расчетов делается сразу, а часть являются отложенными расчетами. При запуске процедуры «Расчет», заданные группы «Первичных табелей» рассчитываются и результаты расчета переносятся в соответствующие группы таблиц-документов «Вторичные табеля». Далее «Вторичные табеля» проводятся по подчиненным справочникам «Табульки сотрудников». Вот этот подчиненный справочник сотрудников является уже вторичной таблицей. Которые затем используются для расчетов в следующих периодах. В будущем думаю проводить не только «вторичные табеля», но и первичные и не только по отчетным периодам, но и по зачетным. Это сильно сократит время расчета зарплаты сотрудников. В «учете ресурсов» реализован ортогональный учет, говорить о котором можно долго.

Бредятина2) МДНУ отменяется. Это оказалась РМД:)
Я этот термин и не предлагал :) .

Бредятина3) На смену "первичной таблицы данных" и "вторичной таблицы данных" приходят "справочник", "перечисление", "обработка", "план счетов", "документ", "регистр" и "журнал документа". Это концепции модели данных, используемой в "универсальном клиенте"?
Это лишь удобные синонимы на этапе перехода от одной системы к другой. Эквивалентность терминов должна быть очевидна.

БредятинаДостаточно обсудить перспективы проектов, в которых:
1) Программисты должны что-то программировать.
2) Пользователи не управляют интерфейсом.
3) Пользователи не могут в управляемом интерфейсе получать нужную им информацию произвольным образом.
Что-то Вы все усложняете. Я исхожу из удобства работы обычных пользователей. Программисты уже доказали свою неспособность писать прикладные конфигурации, ориентированные на собственно учет (типа, не их это дело вникать в бухгалтерию). Посмотрите на проект «2С». Как только возникла необходимость создавать реальные конфигурации на его основе, так проект и заглох, поскольку программисты не хотят заниматься бухгалтерией, а бухгалтера программированием.

БредятинаEmery[1] На уровне хранения данных модель не известна.
[2] Обычная реляционная модель на уровне реализации (отображения).
[3] На прикладном уровне это первичность натуральных операций и вторичность бухгалтерских операций.
Я по-прежнему старательно формализую Ваши высказывания. Постепенно мы приближаемся к истине:)
Объясните чем отличается "уровень реализации (отображения)" от "прикладного уровня"? Казалось бы "уровень отображения" это и есть "прикладной уровень"?
Так какая именно модель данных используется на "прикладном уровне" [3], если он отличается от "уровня отображения" [2]?
Почему писал «неизвестно», так потому, что заинтересовался TR, думал, может быть удастся ее «прилепить» к своей БД. Но, похоже, эта модель не имеет никаких преимуществ, перед той схемой хранения данных, что описана в начале этого топика. Динамическая TR эквивалентна работе со списками, а те в свою очередь работе с индексами. Используя нашу разновидность EAV, мы предполагаем индексировать все поля таблиц, в которых присутствует небольшое количество фиксированных столбцов. В итоге выйдем на ту же производительность, что при TR, но не имея геморроя при разработке новой системы БД.

К «истине» приближаетесь Вы, для меня ничего ни нового, ни непонятного нет.

«Уровень реализации» - это представление (отображение) данных на уровне пользовательского интерфейса. «Прикладной уровень» это реализация методологии учета на уровне кода. Так что для меня это немного разные понятия.

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

БредятинаЯ и не говорил, что Ваше приложение не будет работать:) Вы опять пространными рассуждениями о своем (не умышленно наверное) скрываете простой факт: пользователи не могут получать произвольно нужную им информацию:)
. . .
Нет, Вы ниразу не сказали правду: "Пользователи моего приложения не смогут делать произвольные запросы к БД».
Я этого и не скрывал и это вполне очевидно. Система будет слишком простая, чтобы поддерживать произвольные запросы. Кому нужны средства разработки, пусть юзают другие системы. Вместо этого я хочу сделать конечный продукт. Раз подразумеваются произвольные запросы, значит, кто-то должен настраивать, адаптировать систему для конечных пользователем. Ведь не тетеньки-бухгалтера предпенсионного возраста должны делать эти самые «произвольные запросы»? Они и мышкой то тыкать толком не умеют, а сохранить файл на диск и затем перебросить его в другое место для них вообще неподъемная задача. Им вполне будет достаточно внешних настроек и генератора отчетов уровня пользователя (который все равно придется настраивать мне). Если кто-то сильно хочет, пусть, либо делает внешние запросы из моих dbf-файлов, либо адаптирует под себя исходные тексты программы. Ради Бога! Я уже говорил, что обычные программисты не любят вникать в бухгалтерскую суть. Потому и предлагаемые бухгалтерские программы все такие бестолковые. Последний «шедевр» -бесплатная программа «Дебет-плюс» 12-й версии, написанная на Яве. Этот монстр с трудом идет даже на моей, очень не слабой тачке.

БредятинаEmery Метаинформация по описанию таблиц есть в базе, а по описанию связей нет. Эту связь можно увидеть только в самом коде.
Я так и знал. Но Вы же должны понимять, что "связи" - это те же данные, а данные должны быть отделены от кода:)
Эта связь на уровне первичных и вторичных таблиц или справочников и документов в терминологии 1С. Связь эта вполне фиксированная и достаточно простая для конечных учетных задач, чтобы заниматься ее формализацией и вычленением. Ничего это мне не даст, кроме ненужного усложнения структуры. И даже совершенствование структуры, которая будет в новых проектах, не повод делать «связи» данными. Так что я никому, ничего не должен :) .

БредятинаВы банально не знакомы с проблемами моделирования данных. Не удивительно, что:
1) Вы думаете, что "с серверами БД все в порядке".
2) Вы настраиваете над РМД какие-то свои модели данных с "регистрами" и "документами".
3) Пользователи Ваших приложений не могут извлекать из БД нужную информацию самостоятельно.
Так это у Вас вообще не ПРИЛОЖЕНИЕ БАЗ ДАННЫХ. Сказали бы сразу, что Вы занимаетесь, например, приложениями для работы со "слабоструктурированными данными", или еще что-то вроде этого. Я бы тогда и вопросов не стал задавать:)
Интересно, почему те, «кто знаком с проблемами моделирования данных» не предлагает ничего путного в качестве конечного решения? Почему все предлагаемые решения только «промежуточные» , либо недостаточно комфортные для работы? Заметьте, я ведь никого ни учу «уму-разуму» и не навязываю своих идей, а просто делюсь ними. И почему-то все, считают своим долгом доказать, что я не прав. Если бы существовали удобные для работы системы учета, готовые для работы по факту, а не «в принципе», я бы, поверьте, нашел бы для себя более интересное занятие, чем заниматься программированием учета.

БредятинаВажный момент. Итак, вы ранее, когда я Вас спрашивал о модели данных, надстраиваемой над моделью данных "сервера БД", имели в виду "объектную модель ядра 1с". Очень избыточна. Я думаю, что и большинство понятий, которые Вы зачем то оставили, тоже избыточны:) А вот отсутствие поддержки связей между объектами - это фундаментальный недостаток.
Опять Вы все усложняете. Моя БД это просто набор dbf-файлов, для которых даже контейнер dbc не нужен. Метаданные тоже будут находиться в dbf-файлах. Никаких «объектов модели ядра 1с» не будет, как не нужных. Структура связей будет в коде, но этот код будет хорошо структурирован. Конфигурации доже будут интегрированы в код, но также хорошо структурированы в нем. Максимум настроек будет вынесено наружу, также в dbf-файлы. Естественно, это не будет средством разработки, но я к этому и не стремлюсь. Моя цель – простая, конечная, удобная в работе учетная система. Один человек не сможет удовлетворить все запросы и пожелания. Ему это не под силу. Достаточно, если система будет просто востребована вместо других, аналогичных.

БредятинаEmery Поддерживаются не поддерживаются – не в этом вопрос. Просто без понимания этих различий в таблицах трудно построить оптимальную структуру БД. Не хотите, не применяйте эти термины, я свою идеологию никому не навязываю.
Не хитрите:) Я Вам привел пример, когда одна таблица является и "таблицей первичных данных" и "таблицей вторичных данных". А Вы продолжаете говорить о какой-то идеологии. Очевидно же, что не работает Ваша идеология:)
Таких в моей системе нет, об этом я уже говорил, хотя первичные таблицы могут иметь своими подчиненными вторичные таблицы. Мне эта структура понятна и путаницы не вызывает. Согласен, что другим она может быть непонятна, ибо пока не опубликован весь код с пояснениями, трудно ожидать адекватного восприятия.

БредятинаEmery Я еще не говорил об этом, но таблица сотрудников это очень сложный «справочник».
И правильно сделали:) Почитайте соседнюю тему про Нормальную форму Бойса-Кодда:)
С этого я и начинал программирование своих учетных программ. Только реальной пользы от этого мало. Переключился полностью на свою интуицию и начал постепенно решать стоящие передо мной проблемы. Все получилось, как нельзя лучше. Сейчас пришло время заниматься совершенствованием и оптимизацией своих наработок.

БредятинаEmery Что-то Вы все усложняете. Я исхожу из удобства работы обычных пользователей.
Я все предельно упрощаю. При использовании Вашей "идеологии":
1) Программисты должны постоянно что-то программировать.
2) Пользователи не управляют интерфейсом.
3) Пользователи не могут в управляемом интерфейсе получать нужную им информацию произвольным образом.
Что же здесь сложного?:)
Вам еще не надоело ходить по кругу? Я разрабатываю, внедряю и сопровождаю свои программы, пользователи работают с ней и со своими проблемами идут ко мне. Я заинтересован, чтобы у них таких проблем было поменьше, а свободного времени у меня побольше. Избыток своего свободного времени я хочу потратить на расширение возможностей своих программ. И отнюдь не собираюсь «играть по чужим правилам». Нравиться это кому-то или нет. У меня есть собственные представления, «что такое хорошо и что такое плохо» в программировании учетных задач. Каждый может идти свои путем, доказывая его «правильность» и «истинность». Вот и вся идеология :) .

БредятинаEmery К истине приближаетесь Вы, для меня ничего ни нового, ни непонятного нет.
После того, как Вам пришлось согласиться с тем, что Вы допускали ошибочные высказывания, и Ваша идеология соответсвует давно устаревшим технологиям, я, конечно, соглашусь, что к истине приближаюсь я:)
Вы, с упорством, достойным лучшего применения, навязываете свою точку зрения, как «истину в последней инстанции». Я понимаю, опыта у Вас достаточно, хочется видимо «поучить других» :) . И выдаете желаемое за действительное. Лучше уж предлагайте свои разработки, если что там будет интересного, это будет видно сразу. Вот Вы много говорили про TR. А в итоге, это всего лишь эквивалентное индексам представление данных. Я бы за него патент не дал бы. Впрочем, расходы за поддержку патента нести только Дэйту.

БредятинаEmery «Уровень реализации» - это представление (отображение) данных на уровне пользовательского интерфейса. «Прикладной уровень» это реализация методологии учета на уровне кода. Так что для меня это немного разные понятия.
Отлично. Код совсем не интересен. Так приложение не должно программироваться (это устаревший подход), оно должно проектироваться.
Итак, для ОТОБРАЖЕНИЯ ДАННЫХ НА УРОВНЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ВЫ ИСПОЛЬЗУЕТЕ РЕЛЯЦИОННУЮ МОДЕЛЬ ДАННЫХ!
Мой товарищ по диалогу в теме про нормальную форму Бойса-Кодда должен это оценить:)
Должно / не должно, устаревший / не устаревший – это уже вопросы идеологии. А идеология в современном программировании БД формируется «законодателями мод», т.е. фирмами – разработчиками БД, имеющих явный коммерческий интерес в этом вопросе. Вы желаете блюсти их интересы? Это Ваше право. А я «в чужие игры не играю» :) .

БредятинаЭто уже просто серьезные заблуждения. От недостатка знаний. А говорите, что Вам все понятно:) Конечно, в плену своих заблуждений Вам все понятно.
Не увлекайтесь! Может оказаться, что Ваши слова применимы к Вам большей степени :) .

БредятинаНа самом деле, нет ничего проще конечного продукта, который никто не должен настраивать и адаптировать, чтобы пользователи могли бы делать произвольные запросы. Иначе, приложение вообще нельзя классифицировать как приложение баз данных.
Вы знаете примеры таких программ? Поделитесь! Как минимум нужен перенос данных из предыдущих программ, плохих или хороших неважно, а важно то, что в старых программах эти данные есть, а в новых нет и этих данных очень много, чтобы вводить их повторно вручную. Произвольные запросы нужны тому, кто сопровождает данную учетную систему, а не конечному пользователю. Теоретически это может быть одно и тоже лицо, например, я вдруг захочу вести учет собственной фирмы, а нанять нового человека, при ограниченности средств нет возможности. Могу Вас уверить, что запросы смогу делать произвольные, либо внешним образом к БД, либо внося необходимые изменения в код или структуру данных. Скажу по секрету, иногда это приходится делать в моих конфигурациях «учет ресурсов и начислений». Но обычно времени на это тратиться немного, т.е. все делается в режиме реального времени. Так что проблем особых не возникает. Вы тоже, имея, когда-нибудь, доступ к документации и исходным текстам программы способны делать все то же самое. О чем я уже говорил.

БредятинаEmery Ведь не тетеньки-бухгалтера предпенсионного возраста должны делать эти самые «произвольные запросы»?
Помимо неуважительного отношения к пользвателям Вы еще и сужаете круг пользователей до пользователей, которым не нужны никакие запросы, кроме запрограммированных программистами. Это просто не серьезно.
Может быть это и обидно, но это факт. Я часто говорю своим бухгалтерам. Ну почему я должен вникать в вашу бухгалтерию, а вы не считаете должным для себя вникнуть хотя бы в азы компьютерной грамотности? Есть молодые девчата, которые и компьютер достаточно хорошо знают и в бухгалтерию быстро вникают. Ими я просто не нарадуюсь :) .

Emery ... и генератора отчетов уровня пользователя (который все равно придется настраивать мне).
Зачем? Это же уровень пользователя:)[/quot]
Опыт показывает, что эффективным процесс работы происходит следующим образом. Я показываю новому человеку как работать с программой, ну там вводить документы, делать различные расчеты и отчеты. И через пять минут начинается уже реальная работа с программой. Постепенно, в зависимости от продвинутости и внутренней мотивации пользователь вникает в программу все более и более и наступает момент, когда он уже может самостоятельно сконструировать и распечатать отчет и не только. Обычно это вызывает у него много радости. Но сразу грузить этим, очень не рационально. Более того, одна бухгалтерша материального отдела сказал мне, что «наконец-то я поняла смысл материального учета, после того как начала работать по твоей программе». Хотя никакого бухгалтерского образования у меня нет.

И тут приходите Вы и заявляете, что все я делаю неправильно, имею множество заблуждений и мало знаний :) . Вы думает, я восприму это серьезно?