Здравствуйте, 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. Я делюсь своим маленьким опытом и глупыми мыслями, может у кого-то есть более умные.
