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

>1) Обращение к SQL серверу возвращает таблицу, значит для выборки всех
>полей объекта необходимо многократно обращаться к серверу.

Это если нужно многократно обращаться к серверу.

>2) Применяется (однопользовательский\локальные данные) подход,
>(многопользовательский\удаленные данные) имеет большие накладные
>расходы, и работать с ним нужно по другому - (а) более экономно к
>запросам, (б) данные на сервере могут меняться другими пользователями.

Моя система сделана на основе системы Онтарио. Я ее расширил, хотя и некоторые вещи переписал. Но существенного изменения нет, просто несколько автоматизировал разработку. Так вот

1. Количество объектов 500 000 записей
2. Количество прав объектов 2 000 000 записей
3. Количество записей в регистре проводок. 8 000 000
4. Таблиц всего 300 штук. Классов чуть больше 100. Процедур 3000 штук.
5. Количество пользователей ~ 50. Это на одной базе. А все баз 6 штук в разных регионах страны. Репликация по каналу интернет идет каждые 2 минуты.

Моя система в худшем случае понизит производительность на 20% из-за вытаскивания метаданных перед данными.

>А для создания сложных выборок по соединения нескольких таблиц такая
>схема абсолютно бесполезна.

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



Объекты на клиенте, представлены в виде прокси, т.е. только то что нужно для их идентификации. Это наименование, чтобы показывать в контролах, класс чтобы знать какие метаданные вытаскивать и идентификатор (понятно зачем).

>Привет, а как в вашей объектной системе реализованы вложенные объекты?
>(например: приходная накладная имеет ссылку на контрагента...)

Выше привел пример датасета (многострочная часть документа).
Чтобы открыть объект учета для просмотра, пишем:

var
dbo: TDBObject;
begin
dbo := TDBObject.Create(DBObject.DataSet['Things'].Field['ThingClass'].AsString);
dbo.Retrieve(DBObject.DataSet['Things'].Field['ThingOID'].AsInteger);
dbo.Execute('View');
end;

Набросал доку по своей системе. Кому интересно присылайте мыло, отвечу всем.

Знаю я Ультиму :-)
Ваши траблы я повторять не стал.
Привет Сергею Тарасову.
Я его систему развиваю. :-)

Оригинально и красиво решил проблему ссылочной целостности в своей системе.

Раньше на каждое поле, являющееся ссылкой на объект, нужно было писать процедуру типа

DBODoc_D_DBOState,

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

Сделал все через метаданные.
При регистрации класса в базе добавляется пользовательский тип основанный на int и имеющий название аналогичное классу, например DBODoc, теперь скрипт создания таблицы документов выглядит так

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

Еще кое-что на тему на сайте

dbobjects.boom.ru

Выложил исходники на сайте

http://dbobjects.boom.ru

Ущербный какой-то этот Оракл. Я знал про объекты в нем, вернее про то как они там реализованы, поэтому и не стал его использовать. Лучше взять чистую реляционную СУБД и сделать объект на MIDDLE WARE.

Это большая ошибка, когда проектируют так что данными манипулирует AppServer. Он должен предоставлять интерфейс клиенту и через него манипулировать методами. А данные вытаскивать только в том случае, если их клиент запрашивает для отображения или изменения.

Люди, вы заложники своих стереотипов. Данными манипулировать должны только хранимые процедуры или SQL. А компонент на среднем звене должен представлять собой обертку вокруг разрозненного набора таблиц и процедур, чтобы превратить все это в целостную логическую единицу, представляющую собой сущность, которая может не только иметь данные и операции, но интерфейс для работы с ними.
Мой компонент управляет хранимыми процедурами (серверная часть) и формами (клиентская часть).
Сейчас я делаю подробное описание, как с помощью моего ядра сделать прикладное приложение. Это упрощенная клиентская база. Когда будет готово сообщу. Увидите как все просто.

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

Я перенес сайт на dbobjects.narod.ru