LINUX.ORG.RU

Oracle SQL Developer 2.1.1, Data Modeler Viewer Plugin

 , ,


0

0

Начиная с версии 2.1 в Oracle SQL Developer появился полезный плагин - Data Modeler Viewer. Это урезанная версия отдельного продукта Oracle Data Modeler, предназначенного для проектирования баз данных и, в частности, для построения Entity Relationship диаграмм. Как видно из названия, плагин работает только в режиме просмотра - позволяет отображать на диаграмму существующую схему базы.

На скриншоте вы можете разглядеть ER-диаграмму схемы метамодели БД. Эта универсальная схема позволяет хранить в базе данные любых типов, при этом для добавления объектов новых типов не нужно создавать новых таблиц - типы полностью описываются метаданными (таблицы object_types, attributes, attr_binds). Фактически, такая схема имитирует объектно-ориентированный подход поверх реляционной БД. Для доступа к базе удобно использовать ORM - созданный один раз набор классов-сущностей позволит работать с любыми данными в рамках метамодели.

Оформление Ubuntu 9.10 на скриншоте - дефолтное, не вижу смысла что-то менять.

>>> Просмотр (1280x800, 159 Kb)



Проверено: fagot ()

ORM не нужна, да и Oracle то-же)))

xtron
()

> Оформление Ubuntu 9.10 на скриншоте - дефолтное, не вижу смысла что-то менять.

Ленивый студент на марше. Дефолтная убунта, на которой в Oracle делают базу, которую можно тянуть на access. Таких не берут в космонавты^Wаспиранты.

gods-little-toy ★★★
()

Хоть кто-то занят делом на этом ресурсе.

Тролло выше не слушай. Им не лень пилить Убунту, они располагают временем. :)

ansi ★★★★
()

Начиная с версии 2.1 в Oracle SQL Developer появился полезный плагин


Новое это хорошо забытое старое. Есть такой продукт Together. Его в свое время борланд поглотил и практически похерил. Там Entity Relationship (и другие) диаграмы были уже 10 лет назад. Генерация SQL с создание структуры базы данных. Реверс в Entity Beans и пр. вкусности.

vada ★★★★★
()
Ответ на: комментарий от Zhbert

>мне вот интересно, зачем людям корзина?

Чтобы ее очищать же!

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

WARNING ★★★★
()

И нахрена все пытаются EAV в рбд упорно сделать этот антипаттерн? Ни консистентности, ни удобной навигации и толковых join (для чего rdbms в основном и нужны). А при реальных размерах еще и головняк с шардингом начнется. Гимор со значениями разных типов (case when type then bla bla, т.е. вся оптимизация идет в лес) и т.д. и т.п.

И может не изобретатать лисапед, а посмотреть что есть готового?

На выбор:

  • RDF хранилища (http://www.openrdf.org/ например). Сложные запросы. Не всегда хорошая производительность (но уж точно лучше наколенной поделки). Описание данных при помощи OWL или RDF схем.
  • NoSQL (http://nosql-database.org/) тыщи их. Используют монстры типа twitter, digg или linkedin.
    • document stores - высокая локальность, моментальное чтение, сложный update. нужна сильная денормализация.(Lucene, CouchDB)
    • key/value stores - гибкость, высокая локальность, проще update, сложнее с глубокими структурами. быстрое чтение. нужна сильная денормализация, объекты можно раскладывать по колонкам, а можно сериализовать тем же protobuf или avro (у сериализации есть плюс - не только java может использоваться).
  • колоночные бд (lucidDB, InfoBright) - много колонок и дешевые join-ы и агрегаты, но дорогой read всех колонок за раз. удобны для аналитики.
  • объектные бд (db4o например)- тут вообще ниче не надо, никаких недоORM. Работаешь с оъектами.

Ну и опять же непонятна целевая аудитория этого проекта. Кто-то готов заплатить за «это» и за оракл (еще и enterprise небось)? Почему не pgsql или mysql?

aka50
()
Ответ на: комментарий от BroadSlavonic

Таких продуктов сто тыщ мильонов.


Больше. Тысячамиллионовдонеба.

vada ★★★★★
()
Ответ на: комментарий от WARNING

> мне вот интересно, зачем людям корзина?

Чтобы восстанавливать случайно удалённые файлы. Попробуй отказаться от виндопривычки удалять по Shift-Del и воспользоваться корзиной. Приучил себя года три назад, и доволен. Забыл как выглядят всяческие утилиты по восстановлению файлов.

ZhAN ★★
()

> Дефолтная убунта, на которой в Oracle делают базу, которую можно тянуть на access.

Боюсь, что access быстро сдохнет на запросах, заливающих данные в базу в гигабайтных масштабах (из таблиц плоской модели).

Почему этот дата моделер выглядит как «привет от MSO 2003»? Он под вайном?


Это java-приложение, кроссплатформенное.

Новое это хорошо забытое старое. Есть такой продукт Together. Его в свое время борланд поглотил и практически похерил. Там Entity Relationship (и другие) диаграмы были уже 10 лет назад. Генерация SQL с создание структуры базы данных. Реверс в Entity Beans и пр. вкусности.


Конечно, таких продуктов много. Я хотел сообщить аудитории о том, что в SQL Developer'е появилась такая возможность (а появилась она не так давно). Конечно, для серьезного применения не годится (тот же Oracle Data Modeler стоит ~3000$, а это free), но, например, для контроля правильности строимой схемы в базе годится. Мелочь, а приятно.

И нахрена все пытаются EAV в рбд упорно сделать этот антипаттерн? Ни консистентности, ни удобной навигации и толковых join (для чего rdbms в основном и нужны). А при реальных размерах еще и головняк с шардингом начнется. Гимор со значениями разных типов (case when type then bla bla, т.е. вся оптимизация идет в лес) и т.д. и т.п.

На выбор:



Этот антипаттерн применяется в промышленных масштабах в одной известной международной компании-поставщике информационных систем для телекоммуникационной отрасли. Там было потрачено достаточно много времени на то, чтобы сделать этот подход быстрым и удобным. У решаемых там задач своя специфика (в частности, необходимость гибко добавлять объекты произвольных типов).

И может не изобретатать лисапед, а посмотреть что есть готового? ... Ну и опять же непонятна целевая аудитория этого проекта. Кто-то готов заплатить за «это» и за оракл (еще и enterprise небось)? Почему не pgsql или mysql?


Для меня сейчас это учебный проект, и Oracle (10.2 XE) пользуюсь тоже для изучения. В промышленном применении, естественно, ни о каком mysql и postgres речи идти не может. По поводу клиентов написано чуть выше.

mipt_student
() автор топика
Ответ на: комментарий от ansi

Хоть кто-то занят делом на этом ресурсе.

Спасибо на добром слове :)

mipt_student
() автор топика
Ответ на: комментарий от mipt_student

Боюсь, что access быстро сдохнет на запросах, заливающих данные в базу в гигабайтных масштабах (из таблиц плоской модели).

EAV тоже сдохнет. В моем проекте при 300 полях на сущность (в разных объектах) EAV таблица имела ~600млн строк. Вытаскивание данных по ключу в холодной бд требует до 180 секунд (подзапросы для зависимых данных), при реализации этого-же в виде строгой схемы до 30 секунд на pgsql, в случае hbase с аналогичной бд и большим объемом данных (примерно 3млрд ключ-значений) - 30 запросов в секунду на ноду в кластере.

Этот антипаттерн применяется в промышленных масштабах в одной известной международной компании-поставщике информационных систем для телекоммуникационной отрасли. Там было потрачено достаточно много времени на то, чтобы сделать этот подход быстрым и удобным.

Ну конечно же, мульон мух не могут ошибаться. Ну а уж если билингописатели сидят на oracle, то ошибаться в выборе инструмента они конечно не могут. Особенно обычно весело выглядит валидация данных в таких системах. Ну и естетсвенно производительность и масштабность этих системе запросто может посоперничать с yahoo или twitter? :). Только не рассказывайте сказки, что это билинг хранит так данные. Скорее всего это какая-то CRM, задача которой держать на оборудовании за много килобаксов несколько несчастных десятков миллионов объектов.

Ну и естественно для «заливающих данные в базу в гигабайтных масштабах» думаю имеет смысл отказаться и от fk, ибо иначе скорость не порадует.

У решаемых там задач своя специфика (в частности, необходимость гибко добавлять объекты произвольных типов).

Это могут делать чуть меньше чем все schemaless системы. Даже тот же protobuf(на котором у гугла много чего вертиться) + hbase . Да даже тупая сериализация обктов в виде json - то проще и надежнее (в пране гибкости), ибо в приведенной схеме я не увидел поддержки вложенных структур и структур-массивов. А вот когда это все будет прикручено, то в итоге получим типичное rdf хранилище с типичной производительнстью для этих хранилищь.

В общем, лучше бы изучали предмет (hiload systems) и что в мире по этому поводу делают, а не учили бы oracle на oracle xe и рассказывали, как pgsql или mysql не годятся «В промышленное применении».

aka50
()
Ответ на: комментарий от aka50

> Только не рассказывайте сказки, что это билинг хранит так данные.

Причем здесь биллинг, я же написал: «информационных систем для телекоммуникационной отрасли.» Имеется в виду инвентаризация (телекомовских железок и других ресурсов), планирование, стоимостная оценка и т.д.

Ну и естественно для «заливающих данные в базу в гигабайтных масштабах» думаю имеет смысл отказаться и от fk, ибо иначе скорость не порадует.


Дело вот в чем, смотрите. Высокие нагрузки имеют место в самом начале, когда происходит заливка данных заказчика из его «плоской» базы в нашу объектную. На этом этапе производительность не так важна, процесс может длиться пару суток. Далее, работа заказчика с данными в рабках информационной системы происходит не так интенсивно. Таким образом, это не hi-load система.

ибо в приведенной схеме я не увидел поддержки вложенных структур и структур-массивов.


Это простейшая учебная схема, реально применяемая на порядок объемнее и сложнее.

В общем, лучше бы изучали предмет (hiload systems) и что в мире по этому поводу делают


Может и дойдут руки (спасибо за большое количество ценных указаний по теме!), а сейчас мой предмет состоит немного в другом :)

а не учили бы oracle на oracle xe и рассказывали, как pgsql или mysql не годятся «В промышленное применении».


Имею мнение, что знание oracle мне в жизни пригодится и что можно изучать устройство совеременных БД на его примере.

mipt_student
() автор топика
Ответ на: комментарий от mipt_student

Дело вот в чем, смотрите. Высокие нагрузки имеют место в самом начале, когда происходит заливка данных заказчика из его «плоской» базы в нашу объектную. На этом этапе производительность не так важна, процесс может длиться пару суток. Далее, работа заказчика с данными в рабках информационной системы происходит не так интенсивно. Таким образом, это не hi-load система.

Ну если заказчик определяет бд, тогда конечно сложно что-то обсуждать. Но для такой задачи pgsql/mysql - выше крыши. И существенно дешевле (как в стартовых затратах, так и в последующем масштабировании по чтению).

Это простейшая учебная схема, реально применяемая на порядок объемнее и сложнее.

Дьявол, он как известно в деталях :). К сожалению, большиство систем так и вырастает из студенческих «а вот вроде нагрузка небольшая и так сойдет», а потому волосы на жопе рвут :).

Имею мнение, что знание oracle мне в жизни пригодится и что можно изучать устройство совеременных БД на его примере.

Ничего подобного. Изучать нужно начать с понимания реляцонной теории, затем понять, что она реально нигде не соблюдается, затем понять, что реально существует два мира бд: блокировочники (ms sql, mysql/myisam), версионники c rollback-ом (oracle, mysql/innodb) и чистые версионники (pgsql). И вот уже после этого изучать конкретную бд, т.к. имея опыт более 10 лет на oracle, я под mssql писать не смогу (ну кроме простейших задач), т.к. совершенно иной подход к проектированию многих вещей.

aka50
()
Ответ на: комментарий от aka50

два мира бд: версионники и блокировочники. а уже версионнки делятся на чистые и версионники с ROLLBACK/UNDO

aka50
()
Ответ на: комментарий от aka50

> существует два мира бд: блокировочники (ms sql, mysql/myisam), версионники c rollback-ом (oracle, mysql/innodb) и чистые версионники (pgsql).

Кстати где про это можно почитать? Без сарказма, действительно интересно.

Начиная с версии 2.1 в Oracle SQL Developer появился полезный плагин - Data Modeler Viewer.

Программой давно пользуюсь как удобным инструментом общения с БД. Помнится она с какой-то версии начала поддерживать mysql. Надобно обновиться, посмотреть.

diafour
()

Юзал такую фигню для mssql. полезна для того, чтобы объяснять гуманитариям из какой дырдочки что вытекает...

helios ★★★★★
()
Ответ на: комментарий от aka50

Ну если заказчик определяет бд, тогда конечно сложно что-то обсуждать. Но для такой задачи pgsql/mysql - выше крыши.

Как второе следует из первого? Никак.

Дьявол, он как известно в деталях :). К сожалению, большиство систем так и вырастает из студенческих «а вот вроде нагрузка небольшая и так сойдет», а потому волосы на жопе рвут :).

Так никто не рвет, все отлично работает :)

Изучать нужно начать с понимания реляцонной теории, затем понять...

Не волнуйтесь, в этом направлении я тоже работаю.

На этом предлагаю закончить дискуссию.

mipt_student
() автор топика
Ответ на: комментарий от diafour

Кстати где про это можно почитать?

В докуметнации к БД :) Конкурентный доступ и версионирование в Oracle много где описаны, например в книге Тома Кайта «Expert Oracle Database Architecture».

mipt_student
() автор топика
Ответ на: комментарий от ZhAN

>Попробуй отказаться от виндопривычки удалять по Shift-Del и воспользоваться корзиной.

Попробуйте не удалять нужные файлы, реально помогает;) Ни разу не пользовался утилитами по восстановлению файлов.

З.Ы. в опенбоксе корзины нет, так что удаляю просто по Del.

WARNING ★★★★
()

Может быть я чего-то не знаю, но по-моему это не ER-диаграмма. Больше похоже на IDEF1x.

cisco
()

Пафосно и совершенно бесполезно. (C) Oracle.

slovazap ★★★★★
()
Ответ на: комментарий от yirk

Потому что это L&F от Oracle для Swing. Энтерпрайзненько

Karapuz ★★★★★
()
Ответ на: комментарий от diafour

существует два мира бд: блокировочники (ms sql, mysql/myisam), версионники c rollback-ом (oracle, mysql/innodb) и чистые версионники (pgsql).

Кстати где про это можно почитать? Без сарказма, действительно интересно.

http://en.wikipedia.org/wiki/Multiversion_concurrency_control

А различия реализации mvcc - это опыт. Например pgsql очень страдает от своей реализации для больших объемов и частых апдейтов. Дело в том, что при обновлении строки в oracle старые данные попадают в rollback, а новые пишуться поверх (т.е. сохраняют свое место), то в pgsql создается новая строка в конеце (Или где там есть место) таблицы. В итоге при heavy updates получаем такую кашу, что спасает только vacuum (а это блокировка таблицы) или dump/restore (желательно с сортировкой), что тоже не всегда возможно.

aka50
()

Глянь JDeveloper (sql developer + java IDE)

aydar ★★★★★
()
Ответ на: комментарий от mipt_student

Ну если заказчик определяет бд, тогда конечно сложно что-то обсуждать. Но для такой задачи pgsql/mysql - выше крыши.

Как второе следует из первого? Никак.

Не вижу смысла использовать БД Oracle (5к за 1 кору) для задач отличных от OLTP/OLAP с реальной нагрузкой (т.е. хотяб гигов 100).

Дьявол, он как известно в деталях :). К сожалению, большиство систем так и вырастает из студенческих «а вот вроде нагрузка небольшая и так сойдет», а потому волосы на жопе рвут :).

Так никто не рвет, все отлично работает :)

На пирацком оракле? :)

aka50
()
Ответ на: комментарий от paran0id

>> trololo

Я тоже видел это видео. Впрочем, ответ все сказал за тебя.


Ага щас я тебе буду доказывать какой я крутой осилятор. Разбежался.

//Trolol появилось до видео. btw.

ansi ★★★★
()
Ответ на: комментарий от mipt_student

>> Кстати где про это можно почитать?

В докуметнации к БД :) Конкурентный доступ и версионирование в Oracle много где описаны, например в книге Тома Кайта «Expert Oracle Database Architecture».

Том Кайт - это вообще какая-то икона оракле. Я-то думал есть что-то навроде сравнения внутреннего устройства БД. Похоже как обычно, нужно про каждую в отдельности узнавать.

http://en.wikipedia.org/wiki/Multiversion_concurrency_control

За ключевые слова спасибо (и за отсылки к объектным бд тоже, до этого слышал только про парочку из списка).

В итоге при heavy updates получаем такую кашу, что спасает только vacuum

Похоже, что с переходом на pgsql для 1С мало что поменялось ;)

diafour
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.