Здравствуйте, All.
Чего-то пробило меня написать в форум, да по флеймить. Страдаю от того, в отличие от занятия демагогией, лень заниматься общественно-полезным трудом.
Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер. Генерация OID значительно проще и глобальнее решает эту задачу.
Что такое OID.
OID – некоторый уникальный идентификатор, который идентифицирует объект в течении всей его жизни, и после смерти. То есть:
1. Никакой другой объект не может иметь подобный идентификатор ни до его создания, ни после смерти.
2. Идентификатор создается конструктором объекта и не может быть изменен.
Термин OID взят из теории ООБД. Это был и остается основой построения объектно-ориентированных баз данных.

Где бы этот объект не находился, в другой базе данных, в виде строки (набора строк) БД или DataSet или в виде объекта в оперативной памяти, мы всегда можем сказать – это именно этот объект и никто другой. Нам совершенно не важно, каким образом, из какого источника и по какому маршруту был получен данный объект. Мы всегда знаем, это ОН.
В результате, при синхронизации нескольких хранилищ данных, можно переносить объекты, не изменяя их идентификаторы. Синхронизация не требует переделывать ссылки на данный объект. При построении новой базы данных, у меня привычка создавать primary key как GUID. К сожалению, строить новые базы приходится редко, в основном работать по готовым базам. Однако и тут OID может помочь. Надо только добавить столбец с идентификаторами, навернуть на него индекс, и можно пользоваться на здоровье. Конечно, он уже практически не используется в логике ссылочной целостности, но свою задачу, все-таки выполняет.
Еще другой немаловажный плюс – организация поиска и хранения загруженных объектов. То есть, логика кэширования (типа кэша ASP.NET) или логика согласованного чтения. В Domain Model без подобного механизма вообще делать нечего.

Типы OID
Я рассматриваю 2 вида OID. GUID и уникальный идентификатор+информация о типе.
С GUID все понятно. Это наиболее распространенный и простой способ. Сам его применял и применяю. Для уменьшения размера, вместо GUID’a вполне можно использовать криптографическую функцию генерации случайных чисел, с очень маленькой вероятностью повторения (например 2^-64). Однако получение данного числа в БД — достаточно трудная задача. Да и достаточно тормозная.
С информацией о типе, уже не все так однозначно. Я ее никогда еще впрямую не делал, поэтому здесь все несколько субъективно. В действительности, в нормализованной БД в одну таблицу (набор таблиц) может сохраняться сразу несколько типов объектов. Тогда для выборки объектов определенного типа, нужно вставлять в запрос информацию о типе. Так почему же не сохранять информацию о типе именно в ключе. Что это даст:
1. Возможность выборки объектов определенного типа из таблиц в которых лежат объекты нескольких типов. Возражение для данного пункта — подобная функциональность требуется далеко не для всех таблиц. И не обязательно наличие информации о типе именно в ключе, ее можно хранить отдельным полем.
2. Возможность определения типа при переносе объектов. Например, пришел DataSet. Благодаря информации о типе, из этого датасета можно легко определить какие объекты пришли, и как их обрабатывать. Возражение для данного пункта – не встречается ситуаций когда вызывающая сторона не знает что и зачем она получает.
3. Возможность построения механизма универсального выполнения последовательного сохранения объектов в БД с учетом ссылочной целостности. Возражением для данного пункта – практически все БД имеют механизм отложенной проверки на фазе фиксации. Второе, данный механизм не решает вопроса сохранение зацикленного графа.

Минусы OID вполне понятны. Достаточно большой ключ – который выливается в достаточно большой индекс. На мой взгляд – это не аргумент ради которого можно пожертвовать функциональностью OID. Второй минус – неудобство при запросах. Действительно, весьма неудобно если сравнить:
select * from document where id=1212
select * from document where id=’69A25C12181111D2A52B0000F803A951’
Третий минус – возможность получения OID в супертонком клиенте. Точнее для этого нужно что-то писать.

С уважением, Gleb.

PS. Если вас это словоблудие понравилось, ставьте оценку. Если нет, не стесняйтесь ставить минус. Только не забудьте сказать, почему вы его поставили. Если есть что добавить, wellcome. Я делюсь своим маленьким опытом и глупыми мыслями, может у кого-то есть более умные.

А как поступать, если в качестве DB используется какая-то сторонняя система, например ERP? И клиент по-прежнему тонкий?

Здравствуйте, Poudy, Вы писали:

P>А как поступать, если в качестве DB используется какая-то сторонняя система, например ERP? И клиент по-прежнему тонкий?
В качестве DB или источника данных? Я описывал только DB подконтрольного программисту. Что касается источников в которых нет глобально уникального идентификатор — дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника. Тогда он практически становится глобально-уникальным. Единственная проблема — получение идентификатора источника одинакового для всех частей системы (если система распределена по разным процессам). Если источник вам неподконтролен, то фазу трансформации практически никогда не обойдешь.

С уважением, Gleb.

Поправочка:

дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника.

Должно быть

дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника и информацией(идентификатором) типа объекта

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.

Если еще учитывать, что Янус постоянно глючит в этой области (повторная отправка сообщений), то стоит разобрать другой пример.

GZ>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.

Круто! А не проще оставить ID такие, с которыми удобно работать, а дополнительно хранить хеш по данным (по сообщению) и при постинге проверять наличие такого же хеша? В хеш включить и автора и время создания/изменения сообщения в локальной базе.

Здравствуйте, GlebZ, Вы писали:

Я нигде не прочел "подконтрольной программисту" Прочел тока

"Где бы этот объект не находился, в другой базе данных, в виде строки (набора строк) БД или DataSet..."

GZ>дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника и информацией(идентификатором) типа объекта.

Да, но я немного не об этом. Подконтрольная база — частный случай. Часто объекты и создаются в, и читаются из ERP. Допустим, я нажимаю в браузере "Новый сотрудник..." — допускаешь ли ты, что для этого нужно сразу создавать в ERP нового пустого сотрудника? А что если торчащий наружу метод IOleErpIntrp::crtEmployer пребует параметры?

Интересно узнать твое мнение.

Здравствуйте, Igor Trofimov, Вы писали:

GZ>>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.

iT>Круто! А не проще оставить ID такие, с которыми удобно работать, а дополнительно хранить хеш по данным (по сообщению) и при постинге проверять наличие такого же хеша? В хеш включить и автора и время создания/изменения сообщения в локальной базе.

Это вопрос скорее к AndrewVK. Со своей стороны скажу — важно иметь возможность генерить ID еще на уровне БД. А подключение или написание криптографии на уровне T-SQL и PL/SQL простой не назовешь. К тому-же, скорость генерации хеша очень даже не очень по сравнению с стандартными механизмами. Второе, если сообщение было изменено, то 100% мы будем думать что это новый объект.

С уважением, Gleb.

GZ>С информацией о типе, уже не все так однозначно. Я ее никогда еще впрямую не делал, поэтому здесь все несколько субъективно. В действительности, в нормализованной БД в одну таблицу (набор таблиц) может сохраняться сразу несколько типов объектов. Тогда для выборки объектов определенного типа, нужно вставлять в запрос информацию о типе. Так почему же не сохранять информацию о типе именно в ключе. Что это даст:
GZ>1. Возможность выборки объектов определенного типа из таблиц в которых лежат объекты нескольких типов. Возражение для данного пункта — подобная функциональность требуется далеко не для всех таблиц. И не обязательно наличие информации о типе именно в ключе, ее можно хранить отдельным полем.
GZ>2. Возможность определения типа при переносе объектов. Например, пришел DataSet. Благодаря информации о типе, из этого датасета можно легко определить какие объекты пришли, и как их обрабатывать. Возражение для данного пункта – не встречается ситуаций когда вызывающая сторона не знает что и зачем она получает.
GZ>3. Возможность построения механизма универсального выполнения последовательного сохранения объектов в БД с учетом ссылочной целостности. Возражением для данного пункта – практически все БД имеют механизм отложенной проверки на фазе фиксации. Второе, данный механизм не решает вопроса сохранение зацикленного графа.
Это все не имеет никакого практического значения. Реально информация о типе (да и вообще любая доп.информация) кодируется в OID для одной-единственной цели — облегчить операцию разыменования ссылки. Дело в том, что основная задача OID — вовсе не обеспечение какой-то особенно глобальной уникальности. OID используется как персистентный указатель, т.е. позволяет выполнять две операции:
1. Определять, ссылаются ли два OID на один и тот же объект
2. Разыменовываться, т.е. получать объект по OID.
Так вот, это все — лирика. А практика в том, что для быстрого подъема объекта по указателю крайне желательно знать, где начинать искать этот объект. Как правило, движки ООДБ хранят однотипные объекты рядом (в некотором смысле), поэтому указание конкретного типа сужает область поиска и ускоряет подъем. Более того, зачастую в OID включают не только информацию о типе, но также и идентификаторы сервера и БД, где находится этот объект. Подобные OID, конечно, затрудняют миграцию объектов, но зато позволяют избежать опрашивания всех серверов в поисках запрашиваемого объекта. Когда объект уже найден, обычно нет никакой проблемы определить его тип безо всяких дополнительых хитростей.
Ну и в качестве побочного эффекта, наличие типа прямо в ссылке позволяет выполнять запросы вида is-a без разыменования и/или сопутствующего join. Так, в запросе

select from People where Spouse is Programmer

нет необходимости сканировать целевой домен ссылки Spouse.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, GlebZ, Вы писали:

P>Я нигде не прочел "подконтрольной программисту" Прочел тока
P>

P>"Где бы этот объект не находился, в другой базе данных, в виде строки (набора строк) БД или DataSet..."

Виноват, не развил предусловия задачи . Пропустил уточнение задачи.

GZ>>дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника и информацией(идентификатором) типа объекта.

P>Да, но я немного не об этом. Подконтрольная база — частный случай. Часто объекты и создаются в, и читаются из ERP. Допустим, я нажимаю в браузере "Новый сотрудник..." — допускаешь ли ты, что для этого нужно сразу создавать в ERP нового пустого сотрудника? А что если торчащий наружу метод IOleErpIntrp::crtEmployer пребует параметры?
P>Интересно узнать твое мнение.
Хороший вопрос.
1. Насчет тонкого клиента:
Строка —

Третий минус – возможность получения OID в супертонком клиенте. Точнее для этого нужно что-то писать.

вначале имела другой вид.
Примерно так:

Третий минус — возможность получения OID в супертонком клиенте. Однако в большинстве случаев тонкий клиент не создает сами объекты, а создает запросы на создание объектов. Соответсвенно, генерация уникального идентификатора как и самого объекта производится на сервере.

Перечитав это предложение, мне показалось что я слишком много на себя беру. Я не очень понимаю что такое тонкий клиент. Абсолютно тонкий клиент, который не содержит никакой бизнес логики, точно так же маразматичен как например понятие stateless или statefull. В чистом виде — не встречается. Потому и стер, и поставил ничего не значащее, и к тому же не совсем правильное предложение. По крайней мере стер правильно.

2. Насчет вашего вопроса.
А не доведем ли мы идею до маразма тупым ее использованием? Из контекста я не понял, идет ли POST на ваш сервер, и есть ли он вообще (точнее он может быть вырожден в сервер генерации представления). Если у вас один источник, изменение формата невозможно, вы с объектами работаете поскольку постольку, вам не нужен механизм транзакционности или репликации, все проблемы уже решены до вас. То на фиг это нужно?

3. Может я скажу некоторую глупость, но делать надо так как в сэмплах написано. Имел большой опыт интеграции различных систем (не ERP), документация не всегда совпадает, в большинстве своем сильно не дописана, и имеет кучу своих особенностей и багов (те кто программил Office или не дай бог FineReader меня поймут) .

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:


GZ>Перечитав это предложение, мне показалось что я слишком много на себя беру. Я не очень понимаю что такое тонкий клиент. Абсолютно тонкий клиент, который не содержит никакой бизнес логики, точно так же маразматичен как например понятие stateless или statefull. В чистом виде — не встречается. Потому и стер, и поставил ничего не значащее, и к тому же не совсем правильное предложение. По крайней мере стер правильно.
Терминальные сессии это и есть суппер тонкий клиент

Здравствуйте, GlebZ, Вы писали:


Данный подход хорош когда поле имеет неопределенный тип. В итоге поле состоит из двух полей типа и соответственно значения этакий Variant.
Но имеет смысл только для полей неопределенного типа. Кстати в 1С используется напрополую, но поле имеет именно вариантную запись, хотя для БД лучше иметь два поля (под тип и данные).

Здравствуйте, Sinclair, Вы писали:

S>Это все не имеет никакого практического значения. Реально информация о типе (да и вообще любая доп.информация) кодируется в OID для одной-единственной цели — облегчить операцию разыменования ссылки.
Именно об этом первые два пункта. Только несколько более приземленно. Без теории, только практика. Вопрос был не почему, а вопрос зачем.
S>Дело в том, что основная задача OID — вовсе не обеспечение какой-то особенно глобальной уникальности.
Это немаловажная вещь которая используется в OODB для обеспечения ссылочной целостности и транзакционности. В том числе после смерти объекта.
S>OID используется как персистентный указатель, т.е. позволяет выполнять две операции:
S>1. Определять, ссылаются ли два OID на один и тот же объект
S>2. Разыменовываться, т.е. получать объект по OID.
S>Так вот, это все — лирика. А практика в том, что для быстрого подъема объекта по указателю крайне желательно знать, где начинать искать этот объект. Как правило, движки ООДБ хранят однотипные объекты рядом (в некотором смысле), поэтому указание конкретного типа сужает область поиска и ускоряет подъем. Более того, зачастую в OID включают не только информацию о типе, но также и идентификаторы сервера и БД, где находится этот объект. Подобные OID, конечно, затрудняют миграцию объектов, но зато позволяют избежать опрашивания всех серверов в поисках запрашиваемого объекта. Когда объект уже найден, обычно нет никакой проблемы определить его тип безо всяких дополнительых хитростей.
Нигде не написано что OID есть путь. Есть даже разделение — физический OID — указатель на память где хранится объект, логический OID — идентификатор(который может быть путем) с помощью которого можно получить (или маршализовать в) физический OID. (хотя обычно это скрыто от пользователя).


S>Ну и в качестве побочного эффекта, наличие типа прямо в ссылке позволяет выполнять запросы вида is-a без разыменования и/или сопутствующего join. Так, в запросе
S>

S>select from People where Spouse is Programmer
S>

S>нет необходимости сканировать целевой домен ссылки Spouse.
Это особенности функционирования OQL и OODB. Я веду речь не об этом. Мне более интересно применение информации о типах в приложениях работающих с OODB.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

Мне более интересно применение информации о типах в приложениях работающих с OODB.

Если рассматриваь физическую сущность объектов и их хранение в БД то,
информация о типе нужна
1. Для Вариантных полей.
2. Для полей соднржащий базовый тип.
Например есть абстрактный тип документ, наследники которого отличаются от базового только наличием дополнительных полей.
http://gzip.rsdn.ru/Forum/?mid=408882

Автор: Serginio1
Дата: 13.10.03

По поводу OID то это может быть дополнительное ключевое поле .

Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.

Здравствуйте, GlebZ, Вы писали:

GZ>2. Насчет вашего вопроса.
GZ>А не доведем ли мы идею до маразма тупым ее использованием? Из контекста я не понял, идет ли POST на ваш сервер, и есть ли он вообще (точнее он может быть вырожден в сервер генерации представления). Если у вас один источник, изменение формата невозможно, вы с объектами работаете поскольку постольку, вам не нужен механизм транзакционности или репликации, все проблемы уже решены до вас. То на фиг это нужно?
Да, пожалуй, если все сделали до меня, то не нужно. Вероятно, у меня не всегда один источник. И с транзакционностью не всё в порядке. Мне кажется, Sinclair прав говоря

Автор: Sinclair
Дата: 28.02.05

, что просто от уникальности Oid толку чуть. Он просто должен быть однозначным.

GZ>3. Может я скажу некоторую глупость, но делать надо так как в сэмплах написано. Имел большой опыт интеграции различных систем (не ERP), документация не всегда совпадает, в большинстве своем сильно не дописана, и имеет кучу своих особенностей и багов (те кто программил Office или не дай бог FineReader меня поймут) .
Бывает .

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, GlebZ, Вы писали:

P>Да, пожалуй, если все сделали до меня, то не нужно. Вероятно, у меня не всегда один источник. И с транзакционностью не всё в порядке. Мне кажется, Sinclair прав говоря

Автор: Sinclair
Дата: 28.02.05

, что просто от уникальности Oid толку чуть. Он просто должен быть однозначным.
Ну не говорите вы что уникальность ID бесполезна?
Уважаемый мной Sinclair немного спутал применение OID. Он начал применять его с стороны engine OODB базы. В большинстве случаев, там OID вообще скрыто от пользователя. Оно ему не нужно как таковое. Оно используется только самой OODB в которой уже все является объектами. И эти объекты уже на уровне языка могут смотреть ссылаются ли два OID на один и тот же объект и хранить информацию о типах. Задача OODB просто обеспечить правильное функционирование среды программирования (и это есть гуд). В реляционке об этом приходится либо мечтать, либо использовать что-то типа ORM, или в конце концов самому писать. Только я ни в коем случае не заводил речь об этом. Я написал два случая когда это действительно нужно.
1. Синхронизация различных БД.
2. Нахождение ссылки на один и тот же объект.

С уважением, Gleb.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

S> Мне более интересно применение информации о типах в приложениях работающих с OODB.
Да для OODB это уже все реализовано по умолчанию. Это ее сущность. Главная ее задача обслуживание среды исполнения. OID там в большинстве случаев скрыт. Уже после создания объекта можно работать с информацией о типе средствами среды исполнения (а не средствами ООБД). Заодно там есть средства маршрутизации (если OODB может быть распределенной).


S> Если рассматриваь физическую сущность объектов и их хранение в БД то,
S> информация о типе нужна
S> 1. Для Вариантных полей.
S> 2. Для полей соднржащий базовый тип.
S> Например есть абстрактный тип документ, наследники которого отличаются от базового только наличием дополнительных полей.
S> http://gzip.rsdn.ru/Forum/?mid=408882

Автор: Serginio1
Дата: 13.10.03

Вообще жуткий флейм. Из этого большого куска кода не очень понятно. Попробуй просто разъяснить.(мучаюсь ленью).
Да и еще, я не понял из вопроса, что имелось ввиду: литеральные типы или объектные. На всякий случай скажу — это термины теории OODB, в Net им аналог Value объекты(сравнимые по состоянию) и ссылочные (сравнивымые по ссылке).
Был несколько более жуткий случай. Несколько типов объектов были с одним и тем же набором таблиц и полей РСУБД.

S> По поводу OID то это может быть дополнительное ключевое поле .
Об этом писал.

S> Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.
Тоже немножко не понял. Наверно ты имел ввиду тот флейм. Разъясни.

С уважением, мучающийся ленью, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, GlebZ, Вы писали:

S>> Мне более интересно применение информации о типах в приложениях работающих с OODB.
GZ>Да для OODB это уже все реализовано по умолчанию. Это ее сущность. Главная ее задача обслуживание среды исполнения. OID там в большинстве случаев скрыт. Уже после создания объекта можно работать с информацией о типе средствами среды исполнения (а не средствами ООБД). Заодно там есть средства маршрутизации (если OODB может быть распределенной).


S>> Если рассматриваь физическую сущность объектов и их хранение в БД то,
S>> информация о типе нужна
S>> 1. Для Вариантных полей.
S>> 2. Для полей соднржащий базовый тип.
S>> Например есть абстрактный тип документ, наследники которого отличаются от базового только наличием дополнительных полей.
S>> http://gzip.rsdn.ru/Forum/?mid=408882

Автор: Serginio1
Дата: 13.10.03

GZ>Вообще жуткий флейм. Из этого большого куска кода не очень понятно. Попробуй просто разъяснить.(мучаюсь ленью).
GZ>Да и еще, я не понял из вопроса, что имелось ввиду: литеральные типы или объектные. На всякий случай скажу — это термины теории OODB, в Net им аналог Value объекты(сравнимые по состоянию) и ссылочные (сравнивымые по ссылке).
GZ>Был несколько более жуткий случай. Несколько типов объектов были с одним и тем же набором таблиц и полей РСУБД.

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

По сути БД мало отличается от ООП, хранения данных итд , другие термины и связи.

Но в РСУБД нет понятия неопределенного типа и вариантной записи. Но которая реализуется как некое составное поле (или набор полей) , но разруливается на клиенте правда с огромными издержками.
S>> По поводу OID то это может быть дополнительное ключевое поле .
GZ>Об этом писал.

S>> Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.
GZ>Тоже немножко не понял. Наверно ты имел ввиду тот флейм. Разъясни.

Применение OID как первичного ключа, мне в большей степени видится больше для обмена данными. Та и то ее легко решить через суффиксы (префиксы) ID + IDBD, где IDDB идентификатор БД в которой была создана данная запись. Хотя .....
Для обмена измененных записей легче создать дополнительную таблицу которая будет хранить изменения
ввиде ID таблиы (он же тип), ID записи (Здесь как раз хорош OID или запись с суфиксом ), Флаг изменяемости (довалена, удалена, изменена). Дополнительное поле будет содержать некий ID который, что бы удалить эту запись после получния подтверждения о ее фиксации в другой БД.

Здравствуйте, Serginio1, Вы писали:

Сорри что сразу не врубился, потом понял, теперь совсем понял.
S>Смысл того флейма заключается в создании надстройки ООП над реляционной БД (в контексте локальной БД, и возможности прикручивания ее на стороне сервера, получая при этом гибкость и скорость).
S>Те же понятия валее и ссылочных типов, а так же аноалог Object как поля.

S>По сути БД мало отличается от ООП, хранения данных итд , другие термины и связи.
Если бы так
S>Но в РСУБД нет понятия неопределенного типа и вариантной записи.
S>Но которая реализуется как некое составное поле (или набор полей) , но разруливается на клиенте правда с огромными издержками.
+1

Дело в том, что в свободное время, как многие из соплеменников я пишу программы для души. Маюся, так сказать, интересным но бесполезным трудом. Сейчас делаю OQL парсер. На выходе набор SQL запросов. Свойство вариантности литерального объекта пришлось отмести как класс. Из стандартных средств его можно запихнуть только в блоб или xml, но запихивать тогда в предикат уже нельзя. Соответсвенно, легче программеру сделать поле varchar[4000](или raw[...]) и туда сериализовать, чем какой-то другой способ. А вот что касается ссылок на произвольные объекты то это сделал. Можно ссылаться на несколько произвольных объектов(описанным в метаданных), на наследуемые классы. Ессно, это достигается за счет увеличение кол-ва и сложности SQL запросов. Информация о типе лежащего в БД объекта поддерживается опционально (и используется только когда нужно). В OID она не входит. Без этого в некоторых случаях (например несколько объектов на одной и той же таблице) просто невозможно.


S>>>По поводу OID то это может быть дополнительное ключевое поле .
GZ>>Об этом писал.

S>>> Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.
GZ>>Тоже немножко не понял. Наверно ты имел ввиду тот флейм. Разъясни.

S> Применение OID как первичного ключа, мне в большей степени видится больше для обмена данными. Та и то ее легко решить через суффиксы (префиксы) ID + IDBD, где IDDB идентификатор БД в которой была создана данная запись. Хотя .....
S> Для обмена измененных записей легче создать дополнительную таблицу которая будет хранить изменения
S> ввиде ID таблиы (он же тип), ID записи (Здесь как раз хорош OID или запись с суфиксом ), Флаг изменяемости (довалена, удалена, изменена). Дополнительное поле будет содержать некий ID который, что бы удалить эту запись после получния подтверждения о ее фиксации в другой БД.
Тут не все так просто. Во первых — очень жуткая вещь идентификатор БД. БД имеют свойство пересоздаваться, переноситься, умирать. Кажется у GemStone, есть свойство объектов менять место жительства в зависимости от нагрузки на объект. Во-вторых, существуют сервера обменов основанных на отчуждаемости, то есть объект копируется. Такие системы не волнует что объект пришел с другого сервера. Он не имеет привязки к месту жительства. Единственное когда волнует — синхронизация.
Ну а в третьих, и наверное самое главное, модель деплоинга серверов может составлять из себя граф. То есть объект может быть получен через несколько серверов.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:


GZ>Дело в том, что в свободное время, как многие из соплеменников я пишу программы для души. Маюся, так сказать, интересным но бесполезным трудом. Сейчас делаю OQL парсер. На выходе набор SQL запросов. Свойство вариантности литерального объекта пришлось отмести как класс. Из стандартных средств его можно запихнуть только в блоб или xml, но запихивать тогда в предикат уже нельзя. Соответсвенно, легче программеру сделать поле varchar[4000](или raw[...]) и туда сериализовать, чем какой-то другой способ.
Не совсем. Опять же 1С там вариантное поле составляет 23 символа (у них так или иначе все поля символьные BCD это тоже символьное поле).
Если простой тип помещается то он хранится в этом поле или ссылка (длинные строки кстати сделаны ввиде подчиненой таблицы с длинной записи в 80 символов, с прописыванием длины строки в начачале, опять все разруливается с клиента). Это ускоряет вычисления, не нужно лесть по дополнительной ссылке.

GZ> А вот что касается ссылок на произвольные объекты то это сделал. Можно ссылаться на несколько произвольных объектов(описанным в метаданных), на наследуемые классы. Ессно, это достигается за счет увеличение кол-ва и сложности SQL запросов. Информация о типе лежащего в БД объекта поддерживается опционально (и используется только когда нужно). В OID она не входит. Без этого в некоторых случаях (например несколько объектов на одной и той же таблице) просто невозможно.
В локальных БД это делается очень просто без запросов. Но было бы очень хорошо обрабатывать такие вещи на сервере, с построенной объектной моделью.


GZ>Тут не все так просто. Во первых — очень жуткая вещь идентификатор БД. БД имеют свойство пересоздаваться, переноситься, умирать. Кажется у GemStone, есть свойство объектов менять место жительства в зависимости от нагрузки на объект. Во-вторых, существуют сервера обменов основанных на отчуждаемости, то есть объект копируется. Такие системы не волнует что объект пришел с другого сервера. Он не имеет привязки к месту жительства. Единственное когда волнует — синхронизация.
Иногда это нужно, что бы разруливать конфликты (одновременное изменение записи на разных удаленных распределенных БД), и прменять правила миграции.
GZ>Ну а в третьих, и наверное самое главное, модель деплоинга серверов может составлять из себя граф. То есть объект может быть получен через несколько серверов.

Все зависит от реализации. Ну а в общем согласен с тобой.