Комментарии 14
Интересно, кто-нибудь на практике в реальном проекте использует объектный подход в Oracle? По-моему технология, мягко говоря, не прижилась. Хотя может это только потому, что инструментов удобных нет: создавать такой код вручную больно сложно.
ps. Статья прекрасно бы смотрелась в блоге Oracle.
ps. Статья прекрасно бы смотрелась в блоге Oracle.
На практике используется крайне редко, из крупного вспомню только Oracle OLAP, который интенсивно использует эти возможности, плюс Oracle Spatial (если память мне не изменяет). В основном, это случаи, когда в БД хранятся действительно сложные объекты (ГИС, сборки конструкторских чертежей и т.п.) и академическая сфера.
Инструменты есть, тот же JPublisher.
В блог Oracle перенесу при первой возможности.
Инструменты есть, тот же JPublisher.
В блог Oracle перенесу при первой возможности.
У нас в различных проектах было несколько подходов с попыткой применить подобный код. Результат оказался плачевный — код очень тяжело поддерживать и дорабатывать, весь ООП-функционал намного легче реализовывался средствами обычных языков программирования, существующие подходы и инструменты в конечном итоге все-равно требовали представления данных в стандартной табличной форме.
По секрету скажу что центральный депозитарий Республики казахстан успешно использует объекты в базе данных.
Очень удобно. производительность такая же как у обычных «плоских» таблиц.
Очень удобно. производительность такая же как у обычных «плоских» таблиц.
Около года назад пытался сделать полностью объектно-ориентированную систему. По доке всё хорошо, на наборе тестов объекты тоже неплохо себя показали, всё удобно. Затык случился на версионности объектов. Не могу сейчас записки свои найти, чтобы вспомнить конкретную причину. Какая-то проблема возникала при модификации объекта:
Т.е. помимо основного объекта в словаре остались его предыдущие версии. И было что-то нехорошее, с этим связанное. Склероз, увы :)
В общем, в результате всех этих тестов я понял, что стороннему человеку будет сложно поддерживать эту передовую, удобную, но нестандартную систему. Пришлось отказаться в пользу стандартных реляционных таблиц.
А вот объектные представления это действительно удобно и хорошо. Да и, кажется, сам Кайт говорил, что это наиболее правильное применение объектного функционала оракла.
SQL> create type dropme as object(id int, txt varchar2(30) ); 2 / SQL> alter type dropme add attribute txt2 varchar2(30); SQL> alter type dropme add attribute txt3 varchar2(30); SQL> select owner, object_name, subobject_name, object_type from dba_objects where object_name='DROPME'; OWNER OBJECT_NAME SUBOBJECT_NAME OBJECT_TYPE ------ ------------ --------------- ------------------- TEST DROPME $VSN_1 TYPE TEST DROPME $VSN_2 TYPE TEST DROPME TYPE
Т.е. помимо основного объекта в словаре остались его предыдущие версии. И было что-то нехорошее, с этим связанное. Склероз, увы :)
В общем, в результате всех этих тестов я понял, что стороннему человеку будет сложно поддерживать эту передовую, удобную, но нестандартную систему. Пришлось отказаться в пользу стандартных реляционных таблиц.
А вот объектные представления это действительно удобно и хорошо. Да и, кажется, сам Кайт говорил, что это наиболее правильное применение объектного функционала оракла.
Да, если с объектами работать напрямую, появляется множество проблем.
Например, для того чтобы добавить атрибут, прийдётся сделать:
1. ALTER TYPE
2. CREATE OR REPLACE TYPE BODY (как минимум обновить конструктор)
3. После этого сделать ALTER TABLE UPGRADE, чтобы обновить объектную таблицу до новой версии (для чего версионность типов и вводилась в 9ке)
4. Повторить 2 и 3 пункты для всех сабклассов
С представлений всей этой головной боли нет. Так что Т. Кайт прав, как всегда :)
Например, для того чтобы добавить атрибут, прийдётся сделать:
1. ALTER TYPE
2. CREATE OR REPLACE TYPE BODY (как минимум обновить конструктор)
3. После этого сделать ALTER TABLE UPGRADE, чтобы обновить объектную таблицу до новой версии (для чего версионность типов и вводилась в 9ке)
4. Повторить 2 и 3 пункты для всех сабклассов
С представлений всей этой головной боли нет. Так что Т. Кайт прав, как всегда :)
Недавно опробовал такой подход вкупе с XML-функциями и натолкнулся на сыроватость еще xml-ных функций(например, очень хотел делать выборки а ля select * from xml_sequence(fujnction_returning_cursor())), так что пока на время это отложил.
Понравился безголовый мужик.
Про выйгрыш в производительности при использовании ссылок — как-то очень сомнительно. Вы пробовали создать кластер или хэш-кластер и сравнить производительность для этого случая? Кажется, он будет намного быстрее.
А вот теперь — интересный вопрос.
Как это видно в клиентском (прикладном) коде? Какие нужны средства соединения? Какие платформы поддерживаются? Сохраняются ли все прелести объектной модели на клиентской стороне?
Как это видно в клиентском (прикладном) коде? Какие нужны средства соединения? Какие платформы поддерживаются? Сохраняются ли все прелести объектной модели на клиентской стороне?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование объектных представлений в СУБД Oracle