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

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

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

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

БредятинаEmery Вам то какая разница? Конфигурации работают, все проблемы решают – почему это Вас раздражает? Вот решил подумать об их усовершенствованиях и опять критика. Давно думаю, что надо молча работать :)
Это Вас раздражает то, что Вы не понимаете над чем работаете:) Критиковать, пока, нечего. Вон сколько Вы пишите не по существу, вместо того, чтобы с моей помощью объяснить себе чем Вы занимаетесь.
То чем я занимаюсь представлено на моем сайте http://emery-emerald.narod.ru/ . Единственно, что огорчительно, что развивается он медленно (кроме него я веду еще несколько проектов). Уверен, что мне нужно иметь больше желания его развивать, чем чужого объяснения, «чем я занимаюсь» :) . Про другие проекты, Вы мне тоже будете рассказывать, чем я там занимаюсь :) ?

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

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

БредятинаEmery Понятно, что Вы исходите из своего опыта работы, который отличается от моего. Отсюда и недоразумения. Для меня «проведение» означает «фиксацию данных», с одной стороны и дублирование данных, упорядоченных по другим индексам и / или в других таблицах (с целью ускорения доступа к данным) с другой. Понятно, что под это определение подпадают бухгалтерские проводки. Но для меня они отнюдь не первичны. Для меня первичны натуральные операция, а бухгалтерские операции вторичны. Поэтому и бухгалтерские проводки я программирую сам, а не использую стандартную «Бухгалтерию для Украины», скажем. Также и учет ресурсов и начислений (з/п, в основном) я тоже делаю по своей модели учета, отличной от прикладной модели учета братьев Нуралиевых. Можете сколько угодно доказывать, что я не прав, но моя модель работает и полностью меня удовлетворяет, если не считать ограничений самого ядра 1С77.
Опять многословно уводите от существа вопроса. Откорректировать одну операцию в документе проще и быстрее, чем "перепроводить документ". При чем здесь чей-то опыт???
Чтобы «откорректировать одну операцию» проведенного документа его надо сначала «разморозить», т.е. аннулировать его проведение. Точнее говоря, один «документ ресурсов» у меня может содержать множество «ресурсов документа». Отношение между этими таблицами у меня «один ко многим». Сам процесс проведения у меня реализован на уровне «ресурсов документа», хотя возможно и пакетное проведение / аннулирование проведения на уровне «документа ресурсов» и даже группы таких документов по определенному запросу. Поэтому, если проведенная операция может быть «расфиксированна», то простым нажатием клавиши проведение этой операции аннулируется, вносятся изменения и той же самой клавишей одна эта операция документа снова проводится (фиксируется). Это очень удобно, когда Вы вносите очень много операций в один документ, например, документ ввода остатков или документ амортизации основных средств (который у меня формируется автоматически). Не надо перепроводить весь документ, содержащий тысячи позиций (операций ресурсов документа). Достаточно сделать это только для одной записи документа.

Не исключено, что и это «многословие» не прояснит для Вас ситуацию. Но я уже говорил, когда-нибудь я опубликую полностью этот свой проект с подробными пояснениями всего процесса программирования, хотя это очень трудоемкий объем работ.

БредятинаКакая еще модель отображения? Еще один новый термин:) Ну Вы же сами опубликовали тему в разделе ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ! Как Вы проектируете базу данных? Объясните от начала и до конца. Например, выяснилось, что в предметной области есть люди, которые работают в организациях. И нет больше ничего. Только Люди и Организации, в которых Люди работают:)
Новых терминов действительно много, так как стандартные подходы меня не удовлетворяют, а нестандартные требуют своего языка.

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

Саму модель предметной области, которую я реализовал в своих нестандартных конфигурациях 1С77 (проект «Lional») и собираюсь реализовать в независимом проекте «2E», как я их называю, я постепенно выложу на своем сайте, который я уже цитировал здесь.

Здесь я не собирался обсуждать свои проекты «Lional» и «2Е», кое-что, хотя и очень мало, есть на цитированном сайте. Следите за ним, может быть там будут обновления. Конечно, по ходу дела я отвечал на некоторые вопросы, касающиеся их, но полностью осветить все вопросы в этом топике будет затруднительно. Повторю, моя цель здесь была поделиться своей идеей о новой организации хранения данных. Как оказалось идея не нова и народу особо не нужна. В принципе на этом можно было бы закончить дискуссию. Но если меня спрашивают, то я стараюсь отвечать. А поскольку охват темы достаточно широк, то трудно осветить ее удовлетворительно для всех. Для этого и созданы сайты, подобно цитированному.

БредятинаТо есть, Вы не знаете какова архитектура Вашего решения, и как будете работать с IMS. Ну так бы сразу и сказали:)
Насчет архитектуры я уже объяснил, та, что уже реализована и даже лучше. А какова она – смотрите сайт, постепенно там будет выложена вся необходимая информация.

Что такое IMS? Интернет дает разные варианты этого термина.

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

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

БредятинаEmery Но за счет чего достигается скорость доступа к данным?
Вы про TR? Прочитайте Приложение A в 8-м издании "Введение в системы баз данных" Дейта.
Пожалуй, это будет полезной информацией для меня :) . Спасибо. Постараюсь освоить ее. Хотя будет ли это реальной альтернативой используемой технологии, пока сказать трудно. Нужно время на осмысливание.

iscrafmEmeryВсе сразу увидели в этом один из возможных вариантов EAV. Но сам EAV слишком «широк» и охватывает множество реализаций, не конкретизируя особо ни одну из них. Вот я и предложил свою конкретизацию, которую собираюсь реализовывать в своем клиенте и своей БД.
шутка? Сам EAV как раз слишком "узок".
EAV «широк» относительно собственных реализаций, а не сам по себе.

Я вот читаю сейчас про модель TransRelational (TR), разработанную Стивом Тареном (Steve Tarin) (по наводке «Бредятина»), занятная, надо сказать вещица! Первое впечатление очень хорошее. Действительно, можно обойтись без индексов за счет представления одной «плоской» таблицы двумя таблицами, в первой из которых, все столбцы упорядочены по значениям, независимо от взаимосвязи друг с другом, а вторая представляет собой «таблицу реконструкции записей». Чтобы понять, как она формируется достаточно вникнуть в пример из книги Дейта. Все относительно просто и легко реализуемо. Правда, пока речь идет об уже сформированной БД и доступе к ней только на чтение, но Дейт обещает, что в новой книге, которая готовится к выходу, будут описаны вопросы создания и модификации БД по технологии TR. В принципе, можно попытаться додуматься до этих идей самому и, может быть, все-таки скрестить «ежа и ужа», то бишь TR & EAV :) .

БредятинаСкажите, а "отношения между объектами" тоже представимы своими записями в "плоской" таблице базы данных?
«Отношения между объектами» это и есть записи во вторичных таблицах. Поскольку «линейная» таблица базы данных еще не реализована, то, да, можно сейчас говорить о «плоских» таблицах БД.

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

БредятинаХорошо, пусть это будет "модель натурального учета":)
Рад, что хоть с чем-то Вы согласились :) .

БредятинаEmery Речь шла о собственных конфигурациях в «семерке». Для УК конфигурацией можно назвать его конкретную настройку, так как предполагается, что это будет «конфигурируемый интерфейс».
При чем здесь "семерка"?:) Мы же не вразделе 1с находимся, а в разделе "Проектирование баз данных".
Просто хороший пример. Понятно, что я собираюсь реализовать программу учета, независимую от 1С.

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

БредятинаEmery Я уже сказал, моя собственная модель. Хотите, задавайте, уточняющие вопросы.
Задаю.
Это модель данных в первом значении по Дейту.
Можно сравнивать:
1) Реляционную модель данных (РМД).
2) Классическую объектную модель данных (КОМД).
3) Модель данных натурального учета (МДНУ).
?
Тогда рассмотрим аспект структуры для начала:
1) В РМД основным элементом структуры является отношение.
2) В КОМД основными элементами структуры являются объект и связь между объектами.
3) В МДНУ основными элементами структуры являются ???
Пока моя модель ни к Дэйту, ни к EAV, отношения не имеет. К сожалению, я могу говорить только о своих реализованных нестандартных конфигурациях 1С, с которыми вынужден иметь дело, пока не напишу независимую программу учета. Не знаю даже как мне быть? Рассказывать про 1С, - рискую нарваться на упреки. Говорить о независимой от 1С, но еще нереализованной модели как-то несерьезно.

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

БредятинаСкорее, Вы стараетесь подробно объяснить почему Вы не можете ответить:)
Вам надо следователем работать :) . Конечно, похвально, что Вы интересуетесь всеми нюансами моих исследований, только чтобы хорошо все изложить нужно время и настроение. Лучшая форма для этого сайты. Там можно не спеша подробно все разжевывать. Сейчас у меня нет особого настроения вникать во все детали. Если Вы хотите иметь полную картину, то вряд ли получиться. Материала много и он еще не полностью оптимизирован.

БредятинаНичего Вы не объяснили "насчет архитектуры":)
Архитектуры чего Вы хотите узнать?

БредятинаEmeryЧто такое IMS? Интернет дает разные варианты этого термина.
СУБД, разумеется. От IBM. Мы же о "серверах БД" говорили. Какие могут быть варианты:)
Зачем нам здесь IMS? Вы вот подняли тему TR, но при всей ее «интересности», по ней нет даже полной теории. Есть только метода работы с БД, находящейся в памяти и только на чтение. А многие важные вопросы по TR, которые перечислил Дэйт в резюме по ней, отосланы к книге, которая еще не издана. Получается, что реально это еще «сырая» концепция.

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

БредятинаИтак, уточняем определения:

Первичная таблица данных - таблица определений некоторого объекта, представимого своими записями в «плоской» таблице базы данных.

Вторичная таблица данных - таблица отношений между объектами (определенными в первичных таблицах данных), представимых своими записями в «плоской» таблице базы данных.

И в том, и в другом случае - это просто "таблицы базы данных". Как они формально различаются в модели? Или они различаются только в Вашем сознании (как в сознании Дейта различаются "отношения типа сущности" и "отношения типа связи")?
Думаю, что никак. Да, мы имеем набор таблиц, связи между которыми являются метаинформацией. Эта метаинформация может быть представлена схемами данных, которых я много рисовал на этапе проектировании своей системы (в 1С77). Более того, из всех объектов 1С77 я использовал только справочники, константы, перечисления, обработки и план счетов. Т.е. все таблицы, в том числе документов, регистров и журналов документов, у меня представлены объектами типа «справочник». Все связи, которые я использовал, это отношения «один ко многим» (подчиненные справочники) и «многие к одному» (ссылки на элементы других справочников, по терминологии 1С). Этих возможностей мне оказалось вполне достаточно, чтобы не чувствовать почти никаких ограничений ядра 1С. А так это типичная «реляционная модель».

БредятинаEmery Отнюдь. Я не «увязываю создание универсального клиента со способом хранения данных в БД». Клиент потому и называется универсальным, что должен быть независим от БД. Но функции доступа из клиента в БД, могут иметь стандартизированный формат и определяться своей (внешней) ссылкой.
Наконец-то! Теперь можно забыть об "универсальном клиенте" и вернуться к заявленной теме? Или подразумевалось, все-таки, "Универсальное представление данных в универсальном клиенте"? Или "Универсальное хранение данных - усовершенствованная EAV"? Какая тема-то у нас?:)
У меня не было ни вопросов, ни особого желания говорить о клиенте БД. Это все была попутная информация. Я думал, что информация о «новом» способе хранения данных будет интересна другим. Практически в первых двух страницах темы все точки на «i» по этому вопросу были поставлены. Фактически тему можно было закрывать. Но попутно у народа возникло желание обсудить весь проект целиком. Только здесь, на самом деле два проекта: 1С-овский (нестандартный), который реализован, но еще не до конца оптимизирован, даже на платформе 1С (например, я могу уже отказаться от внешнего приложения VFP, в котором ведется расчет зарплаты и обмен данными с 1С, как DDE-сервером, без потери производительности, и объединить «учет ресурсов» с «учетом начислений» + «бухгалтерский учет») и 1С-независимый проект, который пишется на MFC, но который еще далек от завершения, даже в первом приближении. Понятно, что обсудить подробно эти два проекта в этой теме маловероятно. Просто не тот формат обсуждения.

БредятинаEmeryГоворить о независимой от 1С, но еще нереализованной модели как-то несерьезно.
Еще как серьезно. Не нужно ничего рассказывать нужно просто, для начала, вписать нужный текст в шаблон вопроса:
Рассмотрим аспект структуры для начала:
1) В РМД основным элементом структуры является отношение.
2) В КОМД основными элементами структуры являются объект и связь между объектами.
3) В МДНУ основными элементами структуры являются ???
На «плоском» уровне имеются типичные реляционные отношения между таблицами («один ко многим» и «многие к одному»). Этого мне вполне достаточно. Реализация «один ко многим» производится в виде подчиненной таблицы, а «многие к одному» в виде ссылки на запись другой таблицы. Об этом я уже писал. И реализация и связь, все как в 1С77, только у меня все гораздо проще и как ни странно, менее огрничительно.

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

iscrafmEmery такие системы, как 1С, где программист должен доводить напильником этот «полуфабрикат» до кондиции, меня уже не прикалывают. В итоге, конфигурации запрограммированы очень плохо, вторичное допрограммирование их полупользователями-полупрограммистами делается еще хуже. В конечном счете, на выходе имеем монстра, работать с которым (внедрять, сопровождать) нет ни малейшего желания. Тем более что подобных средств разработки создано уже достаточно, зачем плодить еще одну? Тем не менее, моя система будет открыта, даже не уровне исходных текстов. Так что желающим развивать ее можно будет приложить свои усилия.
Вы же сказали в начале, что системы, где программист должен доводить напильником до кондиции не прикалывают. В итоге предлагаете этим самым программистам развивать то, что вы даже описать толком не можете.
Полностью описать прикладную модель учета на предприятии со всеми нюансами довольно трудно. Это можно сделать только на сайте за довольно продолжительное время. Концептуально это будет обычная реляционная модель на уровне реализации (отображения). На уровне хранения данных модель может быть другая, какая именно, еще точно не определился. На прикладном уровне это первичность натуральных операций и вторичность бухгалтерских операций. Первая версия БД буде реализована в dbf-файлах отображаемых в память по технологии MMF. Интерфейс будет конфигурируемым на базе виртуального режима CListCtrl (MFC). Дальнейшее развитие возможно по различным направлениям, но пока так. Система будет открыта как для пользователей (на уровне настроек, метаданных и пользовательского универсального генератора отчетов), так и на уровне программистов (все коды будут открытыми и подробно описанными в соответствующих статьях). Пользователю будет предлагаться конечная, уже настроенная система, которую ему, в принципе, не обязательно перенастраивать, если только не измениться законодательство или не появятся новые требования руководства. Вот такая общая идея. А нюансов реализации будет еще множество.

БредятинаПонимаю, и, именно поэтому, локализую и конкретизирую. То есть, даже не столько сам анализирую, сколько Вам помогаю анализировать:)
Мне помогать анализировать не нужно. Я это делать сам умею. И по мере возможности делюсь своей информацией с другими. То, что не все понятно, согласен, но ведь и не все еще сказано. Реально Вы можете помочь только новой, неизвестной для меня информацией, как с TR, например. Даже того минимума теории опубликованного по ней достаточно, чтобы пытаться развивать эти идеи самостоятельно, хотя я и не люблю переоткрывать уже известное.

БредятинаEmery Архитектуры чего Вы хотите узнать?
Данных, конечно.
Пока все данные будут храниться в dbf-таблицах. Это то, что я могу сказать однозначно.

БредятинаEmery Зачем нам здесь IMS?
Затем, что "универсальный клиент", не зависит от сервера БД, как Вы сказали. Опять уходите от простых вопросов:)
Почему бы это не сказать сразу? И где на него ссылка?

БредятинаНе сочиняете:) Тему новых направлений в хранении данных подняли Вы, а не я. Я просто расширяю Ваш кругозор. Книга может и не будет никогда издана. Вот здесь критический анализ некоторых аспектов, но однобокий...
http://www.webservertalk.com/message480744.html
Эту страницу я уже находил, когда делал запрос по TR. Если надумаю развивать это направление, то тогда еще вернусь к ней и подобным.

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

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

БредятинаЗамечательно. Осталось понять о какой системе идет речь.
Прототип – мой «учет ресурсов и начислений» на 1С77, оптимизированный вариант которой на ядре 1С77 будет называться «Lional», новая система – проект «2Е», первый намёк на который уже есть на сайте.