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

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


S> Не совсем. Опять же 1С там вариантное поле составляет 23 символа (у них так или иначе все поля символьные BCD это тоже символьное поле).
S> Если простой тип помещается то он хранится в этом поле или ссылка (длинные строки кстати сделаны ввиде подчиненой таблицы с длинной записи в 80 символов, с прописыванием длины строки в начачале, опять все разруливается с клиента).
Немного не понял. 80 символов это максимум? Или по таблице на строку?

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

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

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

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

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

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

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


S>> Не совсем. Опять же 1С там вариантное поле составляет 23 символа (у них так или иначе все поля символьные BCD это тоже символьное поле).
S>> Если простой тип помещается то он хранится в этом поле или ссылка (длинные строки кстати сделаны ввиде подчиненой таблицы с длинной записи в 80 символов, с прописыванием длины строки в начачале, опять все разруливается с клиента).
GZ>Немного не понял. 80 символов это максимум? Или по таблице на строку?
Типа многострочной записи, которая конкатируется. У каждой Записи есть свой ID в таблице представлена как ID строки, номер подстроки, и соответственно подстрока размером 80 элеентов (в большинстве 30 хватает за глаза)

S>>Это ускоряет вычисления, не нужно лесть по дополнительной ссылке.
GZ>Для меня главное сделать все в рамках запроса и эффективно (что ессно не всегда получится). Подразумевается удаленная база. К метаданным подхожу достаточно тщательно, чтобы они могли быть натянуты практически на любую реляционную структуру.
Но в любом случае, хранить ссылки, малые строки, числа, даты имхо лучше хранить в поле. Правда как это буде выглядеть в запросе

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

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

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

S> Типа многострочной записи, которая конкатируется. У каждой Записи есть свой ID в таблице представлена как ID строки, номер подстроки, и соответственно подстрока размером 80 элеентов (в большинстве 30 хватает за глаза)
Ндас. Интересная шняга. Но учитывая что современные субд умеют сокращать размер хранимой строки до реальной, несколько устарело.

S> Но в любом случае, хранить ссылки, малые строки, числа, даты имхо лучше хранить в поле. Правда как это буде выглядеть в запросе

В запросе, например:
//Пример был высосан из головы, на бизнес-логику не обращайте внимание.

select document, document.rubrics where document.name='DocName';

document связан с rubrics через связь 1:n, а также например, имеет вложенный объект address
разложится

select document.*, address.* from document left inner join address on (document.address_oid=address.oid) where document.name='DocName';
select rubric.* from rubric left inner join document on (document.rubrics=rubrics.oid) where document.name='DocName';

То есть возвращается стандартные результирующие наборы. Их только нужно скомпоновать. Это самый простой случай. А учитывая что связки могут быть 1:1, 1:n, m:n, то что объект документ может быть родителем нескольких потомков(которые должны быть получены в результате), работа с хранимыми процедурами и функциями, и учитывая, что я вышел за пределы стандартной ссылочной целостности БД(введя множественный тип ссылки, и ссылки на объекты с наследованием), задача становится очень интересной и нескучной.

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

S> Смотрю я на использование манагед языков на сервере. И если сделать поддержку метаданных на сервере с объектной моделью и выполнение хранимых процедур на них, то .....
Волею судеб я давно работаю с приложениями которые должны одновременно поддерживать несколько видов БД.(В основном Oracle и MS SQL). Мне хотелось бы не привязываться к языку на сервере и не переносить всю логику на хранимки которые платформозависимые.

S> Просто постоянно пишу на 1С. Бысто эффективно без всяких SQL (првда выполнение медленное). Если взять компилируемую надстройку над локальной Бд 1С, то очень быстро по выполнению но не совсем по программированию (правда можно упростить модель с потерей скорости)
Насколько я помню, 1С пришла с клиппера. Не знаю как насчет самого клиппера, но приемы остались те же. Главное — что работает.

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

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



GZ>В запросе, например:
GZ>//Пример был высосан из головы, на бизнес-логику не обращайте внимание.
GZ>

GZ>select document, document.rubrics where document.name='DocName';
GZ>

GZ>document связан с rubrics через связь 1:n, а также например, имеет вложенный объект address
GZ>разложится
GZ>

GZ>select document.*, address.* from document left inner join address on (document.address_oid=address.oid) where document.name='DocName';
GZ>select rubric.* from rubric left inner join document on (document.rubrics=rubrics.oid) where document.name='DocName';
GZ>

К сожалению может быть очень много ветвлений и таких задач достаточно много и получать нужно не одномерную таблицу а некий граф, где и такой запрос не проходит

GZ>То есть возвращается стандартные результирующие наборы. Их только нужно скомпоновать. Это самый простой случай. А учитывая что связки могут быть 1:1, 1:n, m:n, то что объект документ может быть родителем нескольких потомков(которые должны быть получены в результате), работа с хранимыми процедурами и функциями, и учитывая, что я вышел за пределы стандартной ссылочной целостности БД(введя множественный тип ссылки, и ссылки на объекты с наследованием), задача становится очень интересной и нескучной.
Да уж.

S>> Смотрю я на использование манагед языков на сервере. И если сделать поддержку метаданных на сервере с объектной моделью и выполнение хранимых процедур на них, то .....
GZ>Волею судеб я давно работаю с приложениями которые должны одновременно поддерживать несколько видов БД.(В основном Oracle и MS SQL). Мне хотелось бы не привязываться к языку на сервере и не переносить всю логику на хранимки которые платформозависимые.
http://blogs.gotdotnet.ru/personal/tk/PermaLink.aspx?guid=a029be2f-5602-46d7-af59-861a036e2d66
S>> Просто постоянно пишу на 1С. Бысто эффективно без всяких SQL (првда выполнение медленное). Если взять компилируемую надстройку над локальной Бд 1С, то очень быстро по выполнению но не совсем по программированию (правда можно упростить модель с потерей скорости)
GZ>Насколько я помню, 1С пришла с клиппера. Не знаю как насчет самого клиппера, но приемы остались те же. Главное — что работает.
FoxPro

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

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



S> К сожалению может быть очень много ветвлений и таких задач достаточно много и получать нужно не одномерную таблицу а некий граф, где и такой запрос не проходит
Действительно, так. Разлагаем запросы, получается дерево запросов (с сокращением избыточных запросов). При сборке набора результатов (которые могут быть плоскими, или с повтором родительской ссылки если мы знаем что кардинальность небольшая) в объекты или в какой-либо DTO — то возможен и граф. Уж дерево, мы точно получим. В этом весь и смысл.
А учитывая, что я еще заложил получение независимых результатов через один запрос, типа select a, b где a и b никак не связаны друг с другом, то на выходе получается такое.... . Что элементарными SQL запросами еще писать и писать.

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

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

S>> К сожалению может быть очень много ветвлений и таких задач достаточно много и получать нужно не одномерную таблицу а некий граф, где и такой запрос не проходит
GZ>Действительно, так. Разлагаем запросы, получается дерево запросов (с сокращением избыточных запросов). При сборке набора результатов (которые могут быть плоскими, или с повтором родительской ссылки если мы знаем что кардинальность небольшая) в объекты или в какой-либо DTO — то возможен и граф. Уж дерево, мы точно получим. В этом весь и смысл.
GZ>А учитывая, что я еще заложил получение независимых результатов через один запрос, типа select a, b где a и b никак не связаны друг с другом, то на выходе получается такое.... . Что элементарными SQL запросами еще писать и писать.

Эх как это намного проще с локальными БД. Кстати по поводу ссылочки
http://blogs.gotdotnet.ru/personal/tk/PermaLink.aspx?guid=a029be2f-5602-46d7-af59-861a036e2d66

В свое время была информация по сотрудничеству IBM и Борланда по встраиванию Net в DB2 (правда тогда не совсем понял, что именно).
Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться.
Да и обещают Microsoft .NET Business Framework (MNBF) вроде как развивается.

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

S> Эх как это намного проще с локальными БД.
Это проще с базами данных которые имеют навигационный доступ. Многие этого делать не умеют(MS Access).


Кстати по поводу ссылочки
S> http://blogs.gotdotnet.ru/personal/tk/PermaLink.aspx?guid=a029be2f-5602-46d7-af59-861a036e2d66

S>В свое время была информация по сотрудничеству IBM и Борланда по встраиванию Net в DB2 (правда тогда не совсем понял, что именно).
По поводу Oracle, было заявлено о сотрудничестве в области провайдеров к данным Oracle. Что Microsoft объявило как победу разума над маразумом. В действительности, ни одного подтверждения того, что Net встраивается в Oracle я не нашел ни со стороны Oracle ни со стороны Microsoft.
S>Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться.
Да похоже что нет. Навигационный доступ объявили нежизнеспособной технологией.
S>Да и обещают Microsoft .NET Business Framework (MNBF) вроде как развивается.
А я это в принципе делаю пока только для себя. Чтоб жизнь скучной не казалась. Получится коммерчески привлекательным хорошо, не получится ну и ... с ним.

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

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

GZ>Ну не говорите вы что уникальность ID бесполезна?
Не говорю. IMHO, между объектом и Oid связь один ко многим.

GZ>Уважаемый мной Sinclair немного спутал применение OID. Он начал применять его с стороны engine OODB базы.
Не думаю. Есть такой паттерн — Oid, описан в Мацяшеке. Определяется как перзистентная ссылка на объект. Т.е. по ней можно этот объект найти. Единственный объект. Собственно о формате Oid и о том, сколько их может быть, речи не идет.

GZ>Я написал два случая когда это действительно нужно.
GZ>1. Синхронизация различных БД.
GZ>2. Нахождение ссылки на один и тот же объект.
Немного непонятно значение пункта 2. Нахождение ссылки на один и тот же объект?

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


GZ>По поводу Oracle, было заявлено о сотрудничестве в области провайдеров к данным Oracle. Что Microsoft объявило как победу разума над маразумом. В действительности, ни одного подтверждения того, что Net встраивается в Oracle я не нашел ни со стороны Oracle ни со стороны Microsoft.
Но яву то они развивают.
S>>Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться.
GZ>Да похоже что нет. Навигационный доступ объявили нежизнеспособной технологией.

Это как рассматривать. Основная задача уменьшить зависимость транзакции с клиента, а это возможно только за сче создания сервера приложений. Юкон, Oracle с Явой тому подтверждение.
А понятие навигационный способ достаточно растяжимое которое так или иначе применяется и на SQL, когда одним запросом невозможно выудить данные.

GZ> А я это в принципе делаю пока только для себя. Чтоб жизнь скучной не казалась. Получится коммерчески привлекательным хорошо, не получится ну и ... с ним.


От всей души желаю удачи.

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

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

GZ>>Ну не говорите вы что уникальность ID бесполезна?
P>Не говорю. IMHO, между объектом и Oid связь один ко многим.
Между ID и объектом — связь 1:n. Между OID и объектом — 1:1. ID — литеральное значение которое может повторяться между многими объектами. OID глобально уникален и неповторим.

GZ>>Я написал два случая когда это действительно нужно.
GZ>>1. Синхронизация различных БД.
GZ>>2. Нахождение ссылки на один и тот же объект.
P>Немного непонятно значение пункта 2. Нахождение ссылки на один и тот же объект?
Опишу наиболее частый пример. У тебя лежат объекты в кэше(например ASP.NET). В качестве ключа используется OID. Если тебе хочется получить объект имея его идентификтор (в данном случае OID), ты находишь его кэше и не обращаешься в хранилище. В случае ID — такое невозможно, и его надо дополнять какой-то дополнительной информацией для получения уникальности.

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

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

S>>>Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться.
GZ>>Да похоже что нет. Навигационный доступ объявили нежизнеспособной технологией.

S> Это как рассматривать. Основная задача уменьшить зависимость транзакции с клиента, а это возможно только за сче создания сервера приложений. Юкон, Oracle с Явой тому подтверждение.
Да в том то и дело, что Java не очень пошла в Oracle. Я бы не сказал, что ею пользуется много народу. В основном плодятся отдельные сервера приложений. А появилась эта шняга еще в восьмерке, в конце 80-ых.

S> А понятие навигационный способ достаточно растяжимое которое так или иначе применяется и на SQL, когда одним запросом невозможно выудить данные.
Точно также ранее рассудила индустрия РСУБД. Зачем прямой навигационный доступ, если можно примотать механизм SQL. Мне эта аргументация очень не нравится, но таково существующее положение дел.(см 2 манифест ОРСУБД). Кстати, он же хорошо описал разницу между SQL и OODB базами http://www.citforum.ru/database/articles/sql_odmg/$$url1$$

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

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

GZ>Да в том то и дело, что Java не очень пошла в Oracle. Я бы не сказал, что ею пользуется много народу. В основном плодятся отдельные сервера приложений. А появилась эта шняга еще в восьмерке, в конце 80-ых.
А я почему то думал года 2 (имею ввиду хранимые процедуры на Яве)
S>> А понятие навигационный способ достаточно растяжимое которое так или иначе применяется и на SQL, когда одним запросом невозможно выудить данные.
GZ>Точно также ранее рассудила индустрия РСУБД. Зачем прямой навигационный доступ, если можно примотать механизм SQL. Мне эта аргументация очень не нравится, но таково существующее положение дел.(см 2 манифест ОРСУБД). Кстати, он же хорошо описал разницу между SQL и OODB базами http://www.citforum.ru/database/articles/sql_odmg/$$url1$$

В плане навигации не имеет принципиальной разницы
между
DbiGetRecordForKey(DocShapkaCursor,True,0,0,NewID,ShapkaActiveBuffer)

и Seltct * from DocShapka where ID: = NewID

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

Большое Спасибо за ссылочки

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

S> В плане навигации не имеет принципиальной разницы
S> между
S> DbiGetRecordForKey(DocShapkaCursor,True,0,0,NewID,ShapkaActiveBuffer)

S> и Seltct * from DocShapka where ID: = NewID

S> Запросы могут препарироваться.
S> Другое это создание объектной надстройки с применением удобных ОО метаданных над всем этим безобразием и применение обычных коллекций (методов возвращающие эти коллекции), объекты (являющиеся записями или вариантами) итд. Но все это должно быть на стороне сервера
S> Скорость разработки при этом увеличится в разы при отсутствии торможения вычислений.
Именно. При использовании SQL запроса, такие тяжелые механизмы запускаются, мама не горюй. Если бы был специализированный механизм навигации (ессно не теперешьние курсоры), то скорость навигации увеличилась бы на порядок.

Недаром, в рекламе всяких навигационных поделок типа prevayler они пишут, дескать мы работаем в 5000 раз быстрее, чем Oracle.

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

Hello, "GlebZ"
> Чего-то пробило меня написать в форум, да по флеймить. Страдаю от того, в отличие от занятия демагогией, лень заниматься общественно-полезным трудом.
> Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер. Генерация OID значительно проще и глобальнее решает эту задачу.
>

А зачем надо решать задачу гарантированной доставки сообщений на уровне приложения? Для WS уже есть прототипы необходимых спецификаций. Достаточно на клиенте каждому запрому давать уникальный идентификатор — транспорт отслеживает обработанные запросы и препятствует их повторному исполнению.

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

TK>Hello, "GlebZ"
>> Чего-то пробило меня написать в форум, да по флеймить. Страдаю от того, в отличие от занятия демагогией, лень заниматься общественно-полезным трудом.
>> Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер. Генерация OID значительно проще и глобальнее решает эту задачу.
>>

TK>А зачем надо решать задачу гарантированной доставки сообщений на уровне приложения? Для WS уже есть прототипы необходимых спецификаций. Достаточно на клиенте каждому запрому давать уникальный идентификатор — транспорт отслеживает обработанные запросы и препятствует их повторному исполнению.

Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна.
И не всегда оно сможет лечить подобное. Вероятнее всего, с тонкого клиента придет запрос на создание объекта, а не сам объект.

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

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

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

GZ>>Да в том то и дело, что Java не очень пошла в Oracle. Я бы не сказал, что ею пользуется много народу. В основном плодятся отдельные сервера приложений. А появилась эта шняга еще в восьмерке, в конце 80-ых.
S> А я почему то думал года 2 (имею ввиду хранимые процедуры на Яве)
Сорри очепятка. В конце 90-ых кончно

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

Hello, "GlebZ"

> Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна.
>

Здорово. Объект создан. А теперь, начались его изменения. Как OID лечит проблему многократного изменения объекта?

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

TK>Hello, "GlebZ"

>> Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна.
>>

TK>Здорово. Объект создан. А теперь, начались его изменения. Как OID лечит проблему многократного изменения объекта?

Без пруда, не вытащишь и рыбку из него.

1. Что касается Андрея, то там наличие индекса уникальности в БД предотвращает повторный Insert этого объекта. Exception вполне понятен, и реализация реакции я думаю не затруднит.
2. Получение объекта через какой-то механизм. Ну например: паттерн Identity Map в контексте запроса. Защитить от подгрузки объекта, который был уже загружен. Или тот же кэш ASP.NET. Правда тогда надо учитывать контекст — объект изменяемый сразу несколькими запросами очень неприятен. Но тогда можно гарантировать единственность объекта в Application и этим пользоваться.
3. В случае нескольких серверов (типа SOA), защититься от ситуации подгрузки нескольких различных версий одного или того же объекта, либо некоторый механизм аггрегации объекта из нескольких источников(правда эту шнягу не пробовал, только предполагаю).

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

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

GZ>Между ID и объектом — связь 1:n. Между OID и объектом — 1:1. ID — литеральное значение которое может повторяться между многими объектами. OID глобально уникален и неповторим.
Это откуда у тебя такое впечатление сложилось?

GZ>Опишу наиболее частый пример. У тебя лежат объекты в кэше(например ASP.NET). В качестве ключа используется OID. Если тебе хочется получить объект имея его идентификтор (в данном случае OID), ты находишь его кэше и не обращаешься в хранилище. В случае ID — такое невозможно, и его надо дополнять какой-то дополнительной информацией для получения уникальности.
Все это implementation details. Тот факт, что ID-ов (как ты их называешь) может быть много, не мешает провести сличение. Всё-таки я понимаю под Oid ссылку. А то, найдешь ты по ней объект или нет, полностью зависит от твоей реализации подхода.

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

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

GZ>>Между ID и объектом — связь 1:n. Между OID и объектом — 1:1. ID — литеральное значение которое может повторяться между многими объектами. OID глобально уникален и неповторим.
P>Это откуда у тебя такое впечатление сложилось?

между объектом и Oid связь один ко многим.

А у тебя откуда? Что ты имел ввиду?

GZ>>Опишу наиболее частый пример. У тебя лежат объекты в кэше(например ASP.NET). В качестве ключа используется OID. Если тебе хочется получить объект имея его идентификтор (в данном случае OID), ты находишь его кэше и не обращаешься в хранилище. В случае ID — такое невозможно, и его надо дополнять какой-то дополнительной информацией для получения уникальности.
P>Все это implementation details. Тот факт, что ID-ов (как ты их называешь) может быть много, не мешает провести сличение.
Как?
P>Всё-таки я понимаю под Oid ссылку. А то, найдешь ты по ней объект или нет, полностью зависит от твоей реализации подхода.
Да. Но в первую очередь, OID это идентификация объекта. При наличии некоторого механизма, можно говорить о ней как о ссылке. В этом случае, имея OID можно будет получить свойство объекта. Отличие от ссылки в оперативной памяти, как раз и заключается то, что объект в данном случае может быть в разных окружениях. В 3-х звенке — это набор строк в базе данных, объект в оперативной памяти в случае Domain Model, набор полей или например XML в Data Transfer Object и еще в каком-то если понадобится. При этом надо иметь ввиду, что если например к нам пришел объект в DTO, а в это время в БД или оперативки сервера был уничтожен объект, а после этого создан с таким же идентификатором, то система обязана видеть это.
Я как бы это не описывал, посчитал, это дополнительным механизмом который безусловно можно реализовать.

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