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.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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. Я делюсь своим маленьким опытом и глупыми мыслями, может у кого-то есть более умные.
Здравствуйте, Serginio1, Вы писали:
S>>>Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться. GZ>>Да похоже что нет. Навигационный доступ объявили нежизнеспособной технологией.
S> Это как рассматривать. Основная задача уменьшить зависимость транзакции с клиента, а это возможно только за сче создания сервера приложений. Юкон, Oracle с Явой тому подтверждение.
Да в том то и дело, что Java не очень пошла в Oracle. Я бы не сказал, что ею пользуется много народу. В основном плодятся отдельные сервера приложений. А появилась эта шняга еще в восьмерке, в конце 80-ых.
S> А понятие навигационный способ достаточно растяжимое которое так или иначе применяется и на SQL, когда одним запросом невозможно выудить данные.
Точно также ранее рассудила индустрия РСУБД. Зачем прямой навигационный доступ, если можно примотать механизм SQL. Мне эта аргументация очень не нравится, но таково существующее положение дел.(см 2 манифест ОРСУБД). Кстати, он же хорошо описал разницу между SQL и OODB базами http://www.citforum.ru/database/articles/sql_odmg/$$url1$$
Здравствуйте, GlebZ, Вы писали:
S>> К сожалению может быть очень много ветвлений и таких задач достаточно много и получать нужно не одномерную таблицу а некий граф, где и такой запрос не проходит GZ>Действительно, так. Разлагаем запросы, получается дерево запросов (с сокращением избыточных запросов). При сборке набора результатов (которые могут быть плоскими, или с повтором родительской ссылки если мы знаем что кардинальность небольшая) в объекты или в какой-либо DTO — то возможен и граф. Уж дерево, мы точно получим. В этом весь и смысл. GZ>А учитывая, что я еще заложил получение независимых результатов через один запрос, типа select a, b где a и b никак не связаны друг с другом, то на выходе получается такое.... . Что элементарными SQL запросами еще писать и писать.
В свое время была информация по сотрудничеству IBM и Борланда по встраиванию Net в DB2 (правда тогда не совсем понял, что именно).
Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться.
Да и обещают Microsoft .NET Business Framework (MNBF) вроде как развивается.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re: Немного об OID
От:
Аноним
Дата:
28.02.05 11:25
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.
Если еще учитывать, что Янус постоянно глючит в этой области (повторная отправка сообщений), то стоит разобрать другой пример.
GZ>Перечитав это предложение, мне показалось что я слишком много на себя беру. Я не очень понимаю что такое тонкий клиент. Абсолютно тонкий клиент, который не содержит никакой бизнес логики, точно так же маразматичен как например понятие stateless или statefull. В чистом виде — не встречается. Потому и стер, и поставил ничего не значащее, и к тому же не совсем правильное предложение. По крайней мере стер правильно.
Терминальные сессии это и есть суппер тонкий клиент
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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.
Здравствуйте, Poudy, Вы писали:
P>А как поступать, если в качестве DB используется какая-то сторонняя система, например ERP? И клиент по-прежнему тонкий?
В качестве DB или источника данных? Я описывал только DB подконтрольного программисту. Что касается источников в которых нет глобально уникального идентификатор — дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника. Тогда он практически становится глобально-уникальным. Единственная проблема — получение идентификатора источника одинакового для всех частей системы (если система распределена по разным процессам). Если источник вам неподконтролен, то фазу трансформации практически никогда не обойдешь.
дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника.
Должно быть
дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника и информацией(идентификатором) типа объекта
GZ>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.
Круто! А не проще оставить ID такие, с которыми удобно работать, а дополнительно хранить хеш по данным (по сообщению) и при постинге проверять наличие такого же хеша? В хеш включить и автора и время создания/изменения сообщения в локальной базе.
Я нигде не прочел "подконтрольной программисту" Прочел тока
"Где бы этот объект не находился, в другой базе данных, в виде строки (набора строк) БД или DataSet..."
GZ>дополнительно генерить на основе данных уникальный ключ(если явно его нет), и дополнять некоторым идентификтором источника и информацией(идентификатором) типа объекта.
Да, но я немного не об этом. Подконтрольная база — частный случай. Часто объекты и создаются в, и читаются из ERP. Допустим, я нажимаю в браузере "Новый сотрудник..." — допускаешь ли ты, что для этого нужно сразу создавать в ERP нового пустого сотрудника? А что если торчащий наружу метод IOleErpIntrp::crtEmployer пребует параметры?
Здравствуйте, Igor Trofimov, Вы писали:
GZ>>Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер.
iT>Круто! А не проще оставить ID такие, с которыми удобно работать, а дополнительно хранить хеш по данным (по сообщению) и при постинге проверять наличие такого же хеша? В хеш включить и автора и время создания/изменения сообщения в локальной базе.
Это вопрос скорее к AndrewVK. Со своей стороны скажу — важно иметь возможность генерить ID еще на уровне БД. А подключение или написание криптографии на уровне T-SQL и PL/SQL простой не назовешь. К тому-же, скорость генерации хеша очень даже не очень по сравнению с стандартными механизмами. Второе, если сообщение было изменено, то 100% мы будем думать что это новый объект.
Здравствуйте, 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 меня поймут) .
Данный подход хорош когда поле имеет неопределенный тип. В итоге поле состоит из двух полей типа и соответственно значения этакий Variant.
Но имеет смысл только для полей неопределенного типа. Кстати в 1С используется напрополую, но поле имеет именно вариантную запись, хотя для БД лучше иметь два поля (под тип и данные).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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.
Мне более интересно применение информации о типах в приложениях работающих с OODB.
Если рассматриваь физическую сущность объектов и их хранение в БД то,
информация о типе нужна
1. Для Вариантных полей.
2. Для полей соднржащий базовый тип.
Например есть абстрактный тип документ, наследники которого отличаются от базового только наличием дополнительных полей. http://gzip.rsdn.ru/Forum/?mid=408882
По поводу OID то это может быть дополнительное ключевое поле .
Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, GlebZ, Вы писали:
GZ>2. Насчет вашего вопроса. GZ>А не доведем ли мы идею до маразма тупым ее использованием? Из контекста я не понял, идет ли POST на ваш сервер, и есть ли он вообще (точнее он может быть вырожден в сервер генерации представления). Если у вас один источник, изменение формата невозможно, вы с объектами работаете поскольку постольку, вам не нужен механизм транзакционности или репликации, все проблемы уже решены до вас. То на фиг это нужно?
Да, пожалуй, если все сделали до меня, то не нужно. Вероятно, у меня не всегда один источник. И с транзакционностью не всё в порядке. Мне кажется, Sinclair прав говоря
, что просто от уникальности Oid толку чуть. Он просто должен быть однозначным.
GZ>3. Может я скажу некоторую глупость, но делать надо так как в сэмплах написано. Имел большой опыт интеграции различных систем (не ERP), документация не всегда совпадает, в большинстве своем сильно не дописана, и имеет кучу своих особенностей и багов (те кто программил Office или не дай бог FineReader меня поймут) .
Бывает .
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
P>Да, пожалуй, если все сделали до меня, то не нужно. Вероятно, у меня не всегда один источник. И с транзакционностью не всё в порядке. Мне кажется, Sinclair прав говоря
, что просто от уникальности Oid толку чуть. Он просто должен быть однозначным.
Ну не говорите вы что уникальность ID бесполезна?
Уважаемый мной Sinclair немного спутал применение OID. Он начал применять его с стороны engine OODB базы. В большинстве случаев, там OID вообще скрыто от пользователя. Оно ему не нужно как таковое. Оно используется только самой OODB в которой уже все является объектами. И эти объекты уже на уровне языка могут смотреть ссылаются ли два OID на один и тот же объект и хранить информацию о типах. Задача OODB просто обеспечить правильное функционирование среды программирования (и это есть гуд). В реляционке об этом приходится либо мечтать, либо использовать что-то типа ORM, или в конце концов самому писать. Только я ни в коем случае не заводил речь об этом. Я написал два случая когда это действительно нужно.
1. Синхронизация различных БД.
2. Нахождение ссылки на один и тот же объект.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S> Мне более интересно применение информации о типах в приложениях работающих с OODB.
Да для OODB это уже все реализовано по умолчанию. Это ее сущность. Главная ее задача обслуживание среды исполнения. OID там в большинстве случаев скрыт. Уже после создания объекта можно работать с информацией о типе средствами среды исполнения (а не средствами ООБД). Заодно там есть средства маршрутизации (если OODB может быть распределенной).
S> Если рассматриваь физическую сущность объектов и их хранение в БД то, S> информация о типе нужна S> 1. Для Вариантных полей. S> 2. Для полей соднржащий базовый тип. S> Например есть абстрактный тип документ, наследники которого отличаются от базового только наличием дополнительных полей. S> http://gzip.rsdn.ru/Forum/?mid=408882
Вообще жуткий флейм. Из этого большого куска кода не очень понятно. Попробуй просто разъяснить.(мучаюсь ленью).
Да и еще, я не понял из вопроса, что имелось ввиду: литеральные типы или объектные. На всякий случай скажу — это термины теории OODB, в Net им аналог Value объекты(сравнимые по состоянию) и ссылочные (сравнивымые по ссылке).
Был несколько более жуткий случай. Несколько типов объектов были с одним и тем же набором таблиц и полей РСУБД.
S> По поводу OID то это может быть дополнительное ключевое поле .
Об этом писал.
S> Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения.
Тоже немножко не понял. Наверно ты имел ввиду тот флейм. Разъясни.
Здравствуйте, 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
GZ>Вообще жуткий флейм. Из этого большого куска кода не очень понятно. Попробуй просто разъяснить.(мучаюсь ленью). GZ>Да и еще, я не понял из вопроса, что имелось ввиду: литеральные типы или объектные. На всякий случай скажу — это термины теории OODB, в Net им аналог Value объекты(сравнимые по состоянию) и ссылочные (сравнивымые по ссылке). GZ>Был несколько более жуткий случай. Несколько типов объектов были с одним и тем же набором таблиц и полей РСУБД.
Смысл того флейма заключается в создании надстройки ООП над реляционной БД (в контексте локальной БД, и возможности прикручивания ее на стороне сервера, получая при этом гибкость и скорость).
Те же понятия валее и ссылочных типов, а так же аноалог Object как поля.
По сути БД мало отличается от ООП, хранения данных итд , другие термины и связи.
Но в РСУБД нет понятия неопределенного типа и вариантной записи. Но которая реализуется как некое составное поле (или набор полей) , но разруливается на клиенте правда с огромными издержками. S>> По поводу OID то это может быть дополнительное ключевое поле . GZ>Об этом писал.
S>> Обычно для регистрации изменений создается дополнительная таблица, состоящая из 3 основных полей (тип, ID, Флаг изменяемости) и дополнительных полей требующих сохранять данные до регистрации их в другой БД, которые уничтожаются после получения подтверждения. GZ>Тоже немножко не понял. Наверно ты имел ввиду тот флейм. Разъясни.
Применение OID как первичного ключа, мне в большей степени видится больше для обмена данными. Та и то ее легко решить через суффиксы (префиксы) ID + IDBD, где IDDB идентификатор БД в которой была создана данная запись. Хотя .....
Для обмена измененных записей легче создать дополнительную таблицу которая будет хранить изменения
ввиде ID таблиы (он же тип), ID записи (Здесь как раз хорош OID или запись с суфиксом ), Флаг изменяемости (довалена, удалена, изменена). Дополнительное поле будет содержать некий ID который, что бы удалить эту запись после получния подтверждения о ее фиксации в другой БД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Сорри что сразу не врубился, потом понял, теперь совсем понял. 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, есть свойство объектов менять место жительства в зависимости от нагрузки на объект. Во-вторых, существуют сервера обменов основанных на отчуждаемости, то есть объект копируется. Такие системы не волнует что объект пришел с другого сервера. Он не имеет привязки к месту жительства. Единственное когда волнует — синхронизация.
Ну а в третьих, и наверное самое главное, модель деплоинга серверов может составлять из себя граф. То есть объект может быть получен через несколько серверов.
GZ>Дело в том, что в свободное время, как многие из соплеменников я пишу программы для души. Маюся, так сказать, интересным но бесполезным трудом. Сейчас делаю OQL парсер. На выходе набор SQL запросов. Свойство вариантности литерального объекта пришлось отмести как класс. Из стандартных средств его можно запихнуть только в блоб или xml, но запихивать тогда в предикат уже нельзя. Соответсвенно, легче программеру сделать поле varchar[4000](или raw[...]) и туда сериализовать, чем какой-то другой способ.
Не совсем. Опять же 1С там вариантное поле составляет 23 символа (у них так или иначе все поля символьные BCD это тоже символьное поле).
Если простой тип помещается то он хранится в этом поле или ссылка (длинные строки кстати сделаны ввиде подчиненой таблицы с длинной записи в 80 символов, с прописыванием длины строки в начачале, опять все разруливается с клиента). Это ускоряет вычисления, не нужно лесть по дополнительной ссылке.
GZ> А вот что касается ссылок на произвольные объекты то это сделал. Можно ссылаться на несколько произвольных объектов(описанным в метаданных), на наследуемые классы. Ессно, это достигается за счет увеличение кол-ва и сложности SQL запросов. Информация о типе лежащего в БД объекта поддерживается опционально (и используется только когда нужно). В OID она не входит. Без этого в некоторых случаях (например несколько объектов на одной и той же таблице) просто невозможно.
В локальных БД это делается очень просто без запросов. Но было бы очень хорошо обрабатывать такие вещи на сервере, с построенной объектной моделью.
GZ>Тут не все так просто. Во первых — очень жуткая вещь идентификатор БД. БД имеют свойство пересоздаваться, переноситься, умирать. Кажется у GemStone, есть свойство объектов менять место жительства в зависимости от нагрузки на объект. Во-вторых, существуют сервера обменов основанных на отчуждаемости, то есть объект копируется. Такие системы не волнует что объект пришел с другого сервера. Он не имеет привязки к месту жительства. Единственное когда волнует — синхронизация.
Иногда это нужно, что бы разруливать конфликты (одновременное изменение записи на разных удаленных распределенных БД), и прменять правила миграции. GZ>Ну а в третьих, и наверное самое главное, модель деплоинга серверов может составлять из себя граф. То есть объект может быть получен через несколько серверов.
Все зависит от реализации. Ну а в общем согласен с тобой.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S> Не совсем. Опять же 1С там вариантное поле составляет 23 символа (у них так или иначе все поля символьные BCD это тоже символьное поле). S> Если простой тип помещается то он хранится в этом поле или ссылка (длинные строки кстати сделаны ввиде подчиненой таблицы с длинной записи в 80 символов, с прописыванием длины строки в начачале, опять все разруливается с клиента).
Немного не понял. 80 символов это максимум? Или по таблице на строку?
S>Это ускоряет вычисления, не нужно лесть по дополнительной ссылке.
Для меня главное сделать все в рамках запроса и эффективно (что ессно не всегда получится). Подразумевается удаленная база. К метаданным подхожу достаточно тщательно, чтобы они могли быть натянуты практически на любую реляционную структуру.
GZ>> А вот что касается ссылок на произвольные объекты то это сделал. Можно ссылаться на несколько произвольных объектов(описанным в метаданных), на наследуемые классы. Ессно, это достигается за счет увеличение кол-ва и сложности SQL запросов. Информация о типе лежащего в БД объекта поддерживается опционально (и используется только когда нужно). В OID она не входит. Без этого в некоторых случаях (например несколько объектов на одной и той же таблице) просто невозможно. S> В локальных БД это делается очень просто без запросов. Но было бы очень хорошо обрабатывать такие вещи на сервере, с построенной объектной моделью.
Чего и стараюсь сделать. Сервер считается удаленным, и кол-во реальных sql запросов(в том числе вложенных) стараюсь свести к минимуму.
S> Иногда это нужно, что бы разруливать конфликты (одновременное изменение записи на разных удаленных распределенных БД), и прменять правила миграции.
+1
Здравствуйте, 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С, то очень быстро по выполнению но не совсем по программированию (правда можно упростить модель с потерей скорости)
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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С пришла с клиппера. Не знаю как насчет самого клиппера, но приемы остались те же. Главное — что работает.
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
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S> К сожалению может быть очень много ветвлений и таких задач достаточно много и получать нужно не одномерную таблицу а некий граф, где и такой запрос не проходит
Действительно, так. Разлагаем запросы, получается дерево запросов (с сокращением избыточных запросов). При сборке набора результатов (которые могут быть плоскими, или с повтором родительской ссылки если мы знаем что кардинальность небольшая) в объекты или в какой-либо DTO — то возможен и граф. Уж дерево, мы точно получим. В этом весь и смысл.
А учитывая, что я еще заложил получение независимых результатов через один запрос, типа select a, b где a и b никак не связаны друг с другом, то на выходе получается такое.... . Что элементарными SQL запросами еще писать и писать.
Здравствуйте, 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) вроде как развивается.
А я это в принципе делаю пока только для себя. Чтоб жизнь скучной не казалась. Получится коммерчески привлекательным хорошо, не получится ну и ... с ним.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну не говорите вы что уникальность ID бесполезна?
Не говорю. IMHO, между объектом и Oid связь один ко многим.
GZ>Уважаемый мной Sinclair немного спутал применение OID. Он начал применять его с стороны engine OODB базы.
Не думаю. Есть такой паттерн — Oid, описан в Мацяшеке. Определяется как перзистентная ссылка на объект. Т.е. по ней можно этот объект найти. Единственный объект. Собственно о формате Oid и о том, сколько их может быть, речи не идет.
GZ>Я написал два случая когда это действительно нужно. GZ>1. Синхронизация различных БД. GZ>2. Нахождение ссылки на один и тот же объект.
Немного непонятно значение пункта 2. Нахождение ссылки на один и тот же объект?
GZ>По поводу Oracle, было заявлено о сотрудничестве в области провайдеров к данным Oracle. Что Microsoft объявило как победу разума над маразумом. В действительности, ни одного подтверждения того, что Net встраивается в Oracle я не нашел ни со стороны Oracle ни со стороны Microsoft.
Но яву то они развивают. S>>Все равно жизнь заставит применение приемов локальных БД к серверным. Никуда не денуться. GZ>Да похоже что нет. Навигационный доступ объявили нежизнеспособной технологией.
Это как рассматривать. Основная задача уменьшить зависимость транзакции с клиента, а это возможно только за сче создания сервера приложений. Юкон, Oracle с Явой тому подтверждение.
А понятие навигационный способ достаточно растяжимое которое так или иначе применяется и на SQL, когда одним запросом невозможно выудить данные.
GZ> А я это в принципе делаю пока только для себя. Чтоб жизнь скучной не казалась. Получится коммерчески привлекательным хорошо, не получится ну и ... с ним.
От всей души желаю удачи.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 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 — такое невозможно, и его надо дополнять какой-то дополнительной информацией для получения уникальности.
Здравствуйте, 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
Запросы могут препарироваться.
Другое это создание объектной надстройки с применением удобных ОО метаданных над всем этим безобразием и применение обычных коллекций (методов возвращающие эти коллекции), объекты (являющиеся записями или вариантами) итд. Но все это должно быть на стороне сервера
Скорость разработки при этом увеличится в разы при отсутствии торможения вычислений.
Большое Спасибо за ссылочки
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Hello, "GlebZ" > Чего-то пробило меня написать в форум, да по флеймить. Страдаю от того, в отличие от занятия демагогией, лень заниматься общественно-полезным трудом. > Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер. Генерация OID значительно проще и глобальнее решает эту задачу. >
А зачем надо решать задачу гарантированной доставки сообщений на уровне приложения? Для WS уже есть прототипы необходимых спецификаций. Достаточно на клиенте каждому запрому давать уникальный идентификатор — транспорт отслеживает обработанные запросы и препятствует их повторному исполнению.
Posted via RSDN NNTP Server 2.0 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Hello, "GlebZ" >> Чего-то пробило меня написать в форум, да по флеймить. Страдаю от того, в отличие от занятия демагогией, лень заниматься общественно-полезным трудом. >> Некоторое время назад, пришлось мне немного удивиться. AndrewVK сообщил, что в янусе реализован двухфазный протокол транзакций. И все только для того, чтобы предотвратить пользователем повторную отправку данных на сервер. Генерация OID значительно проще и глобальнее решает эту задачу. >>
TK>А зачем надо решать задачу гарантированной доставки сообщений на уровне приложения? Для WS уже есть прототипы необходимых спецификаций. Достаточно на клиенте каждому запрому давать уникальный идентификатор — транспорт отслеживает обработанные запросы и препятствует их повторному исполнению.
Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна.
И не всегда оно сможет лечить подобное. Вероятнее всего, с тонкого клиента придет запрос на создание объекта, а не сам объект.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Да в том то и дело, что Java не очень пошла в Oracle. Я бы не сказал, что ею пользуется много народу. В основном плодятся отдельные сервера приложений. А появилась эта шняга еще в восьмерке, в конце 80-ых. S> А я почему то думал года 2 (имею ввиду хранимые процедуры на Яве)
Сорри очепятка. В конце 90-ых кончно
Hello, "GlebZ"
> Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна. >
Здорово. Объект создан. А теперь, начались его изменения. Как OID лечит проблему многократного изменения объекта?
Posted via RSDN NNTP Server 2.0 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Hello, "GlebZ"
>> Задачу гарантированной доставки я разве где-то упоминал? В данном случае, имелось ввиду что с помощью OID легко организовать механизм единственного инстанса объекта. Задачу януса — это лечит побочно. Там по логике, и задача гарантированной доставки не нужна. >>
TK>Здорово. Объект создан. А теперь, начались его изменения. Как OID лечит проблему многократного изменения объекта?
Без пруда, не вытащишь и рыбку из него.
1. Что касается Андрея, то там наличие индекса уникальности в БД предотвращает повторный Insert этого объекта. Exception вполне понятен, и реализация реакции я думаю не затруднит.
2. Получение объекта через какой-то механизм. Ну например: паттерн Identity Map в контексте запроса. Защитить от подгрузки объекта, который был уже загружен. Или тот же кэш ASP.NET. Правда тогда надо учитывать контекст — объект изменяемый сразу несколькими запросами очень неприятен. Но тогда можно гарантировать единственность объекта в Application и этим пользоваться.
3. В случае нескольких серверов (типа SOA), защититься от ситуации подгрузки нескольких различных версий одного или того же объекта, либо некоторый механизм аггрегации объекта из нескольких источников(правда эту шнягу не пробовал, только предполагаю).
Здравствуйте, 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, а в это время в БД или оперативки сервера был уничтожен объект, а после этого создан с таким же идентификатором, то система обязана видеть это.
Я как бы это не описывал, посчитал, это дополнительным механизмом который безусловно можно реализовать.
Здравствуйте, GlebZ, Вы писали:
P>>Это откуда у тебя такое впечатление сложилось? GZ>
GZ>между объектом и Oid связь один ко многим.
GZ>А у тебя откуда? Что ты имел ввиду?
У меня от чтения Мацяшека и еще что-то, чего уже не помню.
P>>Всё-таки я понимаю под Oid ссылку. А то, найдешь ты по ней объект или нет, полностью зависит от твоей реализации подхода. GZ>Да. Но в первую очередь, OID это идентификация объекта. При наличии некоторого механизма, можно говорить о ней как о ссылке. В этом случае, имея OID можно будет получить свойство объекта. Отличие от ссылки в оперативной памяти, как раз и заключается то, что объект в данном случае может быть в разных окружениях.
Меня вот что смущает: есть offline клиент, который создает какие-то объекты. Естесственно, что в сервисе (т.е. ERP или DB) никаких объектов не создается. Потом все это пулится на сервер. Как проводить различие между объектами, для которых есть соответствие в базе, и новыми объектами?
Как я понимаю, нужно либо разносить их по двум разным "доменам", и потом переложить из домена "временные" в домен "постоянные". Либо отразить новизну в Oid (например указав в Oid что-то типа домена). В первом случае сменится домен, во втором — появится еще один Oid. Особой разницы между этими способами нет. В любом случае нежелательно сохранять ссылки на временные объекты в базу и с этим что-то приходится делать.
В 3-х звенке — это набор строк в базе данных, объект в оперативной памяти в случае Domain Model, набор полей или например XML в Data Transfer Object и еще в каком-то если понадобится. При этом надо иметь ввиду, что если например к нам пришел объект в DTO, а в это время в БД или оперативки сервера был уничтожен объект, а после этого создан с таким же идентификатором, то система обязана видеть это. GZ>Я как бы это не описывал, посчитал, это дополнительным механизмом который безусловно можно реализовать.
GZ>С уважением, Gleb.
Здравствуйте, Poudy, Вы писали:
P>Меня вот что смущает: есть offline клиент, который создает какие-то объекты. Естесственно, что в сервисе (т.е. ERP или DB) никаких объектов не создается. Потом все это пулится на сервер. Как проводить различие между объектами, для которых есть соответствие в базе, и новыми объектами?
P>Как я понимаю, нужно либо разносить их по двум разным "доменам", и потом переложить из домена "временные" в домен "постоянные". Либо отразить новизну в Oid (например указав в Oid что-то типа домена). В первом случае сменится домен, во втором — появится еще один Oid. Особой разницы между этими способами нет. В любом случае нежелательно сохранять ссылки на временные объекты в базу и с этим что-то приходится делать.
Зачем так? У тебя информация от offline клиента — какой-нибудь вид DTO. Берешь подряд объекты, если оказался новым — загружаешь в домен, если старый — поднимаешь реальный объект(если нужна информация из старого объекта) и запускаешь процедуру синхронизации для данного объекта, для удаленных — своя логика. Просто не разыменовывая в объекты домена, а оставляя в том виде в котором они пришли. В результате и получишь исходное состояние. oid в смысле идентификации считай что в действии.(ессно, я не знаю полностью задачи, это примерный алгоритм который я бы сразу улучшил — сейчас важна концептуальность).
GZ>>С уважением, Gleb.
Здравствуйте, GlebZ, Вы писали:
GZ>Зачем так? У тебя информация от offline клиента — какой-нибудь вид DTO. Берешь подряд объекты, если оказался новым — загружаешь в домен,
Как ты узнал, что он новый — по Oid ?
GZ>если старый — поднимаешь реальный объект(если нужна информация из старого объекта) и запускаешь процедуру синхронизации для данного объекта, для удаленных — своя логика.
Угу, а еще есть объекты домена, в которых есть ссылки на новые объекты клиента.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
P>Как ты узнал, что он новый — по Oid ?
А информация о присутсвии или отсутвии OID в системе доменных объектов или на БД тебе мало?
GZ>>если старый — поднимаешь реальный объект(если нужна информация из старого объекта) и запускаешь процедуру синхронизации для данного объекта, для удаленных — своя логика.
P>Угу, а еще есть объекты домена, в которых есть ссылки на новые объекты клиента.
Да на здоровье.
Давай про велосипеды. Возьмем к примеру базу данных. У нее есть две согласованные формы — до вставки изменений, и после внесении изменений. Пока база находится в несогласованном состоянии, это не должно влиять на работу остальной бизнес-логики.
В данном случае, у нас есть два способа:
1. База проверяет согласованность состояния сразу при внесении изменения в базу (например проверяет ссылки). Этот способ по умолчанию, но он ограничивает нас, так как при этом нужен определенный порядок внесения изменений. Чтобы база находилась в согласованном состоянии, при каждом изменении.
2. База проверяет согласованность состояния перед commit. Но в данном случае, есть опасность работы с еще не проапдейченным объектом, который не находится в согласованном состоянии. То есть, ответственность кладется на клиента. Обычно при таком режиме работы, клиент не перечитывает данные. Можно поперхнуться.
Вот и все. Задача в данном случае — привести систему доменов из одного согласованного состояния, в другое. И если ты начнешь плодить сущности (которые могут быть в несогласованном состоянии), то это лично твоя проблема и головная боль. Значит тебе этот гемморой, по каким то независищим от тебя причинам, слишком сильно нужен.
С уважением, Gleb.
PS:Повторюсь, я не знаю саму постановку задачи. Все субъективно и ИМХО.
Здравствуйте, GlebZ, Вы писали:
GZ>В результате, при синхронизации нескольких хранилищ данных, можно переносить объекты, не изменяя их идентификаторы. Синхронизация не требует переделывать ссылки на данный объект. При построении новой базы данных, у меня привычка создавать primary key как GUID. К сожалению, строить новые базы приходится редко, в основном работать по готовым базам. Однако и тут OID может помочь. Надо только добавить столбец с идентификаторами, навернуть на него индекс, и можно пользоваться на здоровье. Конечно, он уже практически не используется в логике ссылочной целостности, но свою задачу, все-таки выполняет.
Строго между нами девочками. Тому кто руками напишет полноценную репликацию, становится по барабану — применяется OID в базе или не применяется. Знаешь почему? Потому что реплицируются данные, а не OID-ы.
OID дает всего лишь унифицированную идентификацию объекта. Что облегчает некоторые вопросы программирования.
Все остальные преимущества — всего лишь плод воображения
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, GlebZ, Вы писали:
GZ>>В результате, при синхронизации нескольких хранилищ данных, можно переносить объекты, не изменяя их идентификаторы. Синхронизация не требует переделывать ссылки на данный объект. При построении новой базы данных, у меня привычка создавать primary key как GUID. К сожалению, строить новые базы приходится редко, в основном работать по готовым базам. Однако и тут OID может помочь. Надо только добавить столбец с идентификаторами, навернуть на него индекс, и можно пользоваться на здоровье. Конечно, он уже практически не используется в логике ссылочной целостности, но свою задачу, все-таки выполняет.
КД>Строго между нами девочками. Тому кто руками напишет полноценную репликацию, становится по барабану — применяется OID в базе или не применяется. Знаешь почему? Потому что реплицируются данные, а не OID-ы.
Потому что ты подразумеваешь что переносишь простые данные а не состояние объектов имеющих некоторые законы целостности. И в этих законах — primary key имеет не последнюю роль.
Представим себе сеть филиалов. При репликации — объекты переносятся. Но там уже есть объекты с данным primary key. Хорошо, изменили primary key. Но в действительности — этот primary key еще имеет смысловую нагрузку. И если тебе понадобилось перенести объекты которые ссылаются на данный объект — ты уже никогда их не привяжешь.
То, о чем ты говоришь подразумевает наличие полной копии бд на хостах. Иначе, начинается большие пляски с бубном.
КД>OID дает всего лишь унифицированную идентификацию объекта. Что облегчает некоторые вопросы программирования. КД>Все остальные преимущества — всего лишь плод воображения
Практика, батенька, практика.
Здравствуйте, GlebZ, Вы писали:
GZ>Представим себе сеть филиалов. При репликации — объекты переносятся. Но там уже есть объекты с данным primary key. Хорошо, изменили primary key. Но в действительности — этот primary key еще имеет смысловую нагрузку. И если тебе понадобилось перенести объекты которые ссылаются на данный объект — ты уже никогда их не привяжешь. GZ>То, о чем ты говоришь подразумевает наличие полной копии бд на хостах. Иначе, начинается большие пляски с бубном.
Я вообще не силен в высоких материях, но полагаю что изменение PK — это явно дурной тон
У нас он точно не меняется
То что я подразумеваю, говорит о наличии таблицы переназначения первичных ключей в БД.
GZ>Практика, батенька, практика.
С сентября прошлого года 20 независимо существущих БД с данными о сделках с недвижимостью Липецкой Области, ежедневно сливают данные в центральные базы
OID на уровне базы у нас есть, но я уже года два как перестал с ним носится и размахивать над головой Красиво, но не более.
В форуме по БД можно найти мои сообщения про нашу репликацию и саму базу.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, GlebZ, Вы писали:
GZ>>Представим себе сеть филиалов. При репликации — объекты переносятся. Но там уже есть объекты с данным primary key. Хорошо, изменили primary key. Но в действительности — этот primary key еще имеет смысловую нагрузку. И если тебе понадобилось перенести объекты которые ссылаются на данный объект — ты уже никогда их не привяжешь. GZ>>То, о чем ты говоришь подразумевает наличие полной копии бд на хостах. Иначе, начинается большие пляски с бубном.
КД>Я вообще не силен в высоких материях, но полагаю что изменение PK — это явно дурной тон КД>У нас он точно не меняется
Абсолютно согласен.
КД>То что я подразумеваю, говорит о наличии таблицы переназначения первичных ключей в БД.
Ага.
GZ>>Практика, батенька, практика.
КД>С сентября прошлого года 20 независимо существущих БД с данными о сделках с недвижимостью Липецкой Области, ежедневно сливают данные в центральные базы
На основе таблицы перекодировок?
КД>OID на уровне базы у нас есть, но я уже года два как перестал с ним носится и размахивать над головой Красиво, но не более.
Ваше право. Никто не навязывается.
КД>В форуме по БД можно найти мои сообщения про нашу репликацию и саму базу.
Время будет, поищу. Или дай ссылочку, очень интересно почтать.
Здравствуйте, GlebZ, Вы писали:
КД>>С сентября прошлого года 20 независимо существущих БД с данными о сделках с недвижимостью Липецкой Области, ежедневно сливают данные в центральные базы GZ>На основе таблицы перекодировок?
Да, при восстановлении некоторых объектов они сначала ищутся по таблице перекодировок, если не находятся — то ищутся по данным объекта.
Есть объекты, которые восстанавливаются только на основании таблицы перекодировок, если не находятся — выполняется insert
А есть которые в гробу видели эту таблицу и поиск эквивалентного объекта производится по описанию
Сейчас центральная база больше 8GB, таблица перекодировки в районе 14 млн записей.
Логика восстановления (впрочем, как и резервирования) пишется на VBS. Сам репликатор — на плюсах
Все базы на FireBird 1.5.2
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
. Что элементарными SQL запросами еще писать и писать.
. Пропустил уточнение задачи.
.
(имею ввиду хранимые процедуры на Яве)
