Вот несколько соображений относительно навигации по схеме базы данных:
стандарты
Стандарт SQL-92 определяет, как СУБД должна реализовывать INFORMATION_SCHEMA, содержащую их словарные таблицы. И действительно, некоторые РСУБД реализуют части стандартной спецификации. Эти СУБД поставляются с некоторой реализацией стандарта.
Близко к стандарту
- HSQLDB: очень близко к истинному стандарту
- Postgres: близко к стандарту, с некоторыми изменениями (также есть собственные словарные таблицы)
- SQL Server: близко к стандартному, но довольно неполный (также имеет собственные таблицы словарей)
Либеральная интерпретация стандарта
- H2 (некоторые назад несовместимые изменения, в последнее время)
- MySQL (только начиная с 5.0, также есть собственные словарные таблицы)
Другие СУБД предоставляют свое собственное представление о словарных таблицах. Это очень сложно для инструментов навигации по схеме, таких как jOOQ. Пейзаж словарной таблицы можно описать так (мое предвзятое мнение):
Аккуратные и хорошо документированные словарные таблицы
- DB2: Эти словарные таблицы как-то похожи на стандартные с разными именами. Они чувствуют себя интуитивно.
- Oracle: По моему мнению, набор словарных представлений лучше, чем те, которые предлагаются стандартом. Очень легко понять и хорошо задокументировано по всему Интернету
- SQLite: нет словарных таблиц, но хранимые процедуры SQLite очень просты в использовании. Это простая база данных, в конце концов
Трудно понять, плохо документированные словарные таблицы
- Дерби: Создано понятие конгломератов вместо использования обычных баз данных, таких как отношения, ключи и т. Д.
- MySQL: старая схема mysql была довольно болезненной. К счастью, это больше не относится к MySQL 5.0
- Ingres: Ну … Ingres — это старая база данных . Юзабилити не была одной из главных вещей в 70-х годах…
- Sybase SQL Anywhere: множество объектов, которые необходимо объединить в сложные отношения. Документация недостаточна
- Sybase ASE: еще сложнее, чем SQL Anywhere. Некоторые данные можно получить только с помощью «хитростей»
JDBC абстракция
Разнообразие таблиц словаря, кажется, требует стандартной абстракции. Хотя стандарт SQL-92 может быть реализован на большинстве этих СУБД, абстракция JDBC еще лучше. JDBC знает об объекте DatabaseMetaData и позволяет легко перемещаться по схемам базы данных. К сожалению, время от времени этот API создает исключение SQLFeatureNotSupportedException . Не существует общего правила о том, какой драйвер JDBC реализует объем этого API и когда требуется обходной путь. Для генерации кода jOOQ эти факты делают этот API совершенно бесполезным.
Другие инструменты
Как уже упоминалось ранее, в мире открытого исходного кода есть и другие инструменты. Вот некоторые недостатки использования этих инструментов в jOOQ:
- Оба инструмента, о которых я знаю, лицензированы LGPL , который несовместим с лицензией Apache 2 от jOOQ.
- Оба инструмента очень хорошо ориентируются в отношениях между сущностями, но, похоже, им не хватает поддержки многих нестандартных конструкций, таких как UDT, расширенное использование хранимых процедур (например, возврат курсоров, UDT и т. Д.), ARRAY.
- SchemaCrawler поддерживает только 8 RDBMS, в jOOQ теперь 12
- Оба инструмента довольно неактивны. Смотрите здесь и здесь
Для получения дополнительной информации посетите их сайты:
jooq-мета
По вышеуказанным причинам jOOQ поставляется с собственной навигацией по схеме базы данных: jooq-meta. Этот модуль может использоваться независимо в качестве альтернативы JDBC DatabaseMetaData, SchemaCrawler или SchemaSpy. jooq-meta использует созданные jOOQ запросы для навигации по метаданным базы данных, поэтому он также является частью набора интеграционных тестов. В качестве примера посмотрите, как отношения внешнего ключа Ingres перемещаются с помощью jooq-meta:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
Result<Record> result = create() .select( IirefConstraints.REF_CONSTRAINT_NAME.trim(), IirefConstraints.UNIQUE_CONSTRAINT_NAME.trim(), IirefConstraints.REF_TABLE_NAME.trim(), IiindexColumns.COLUMN_NAME.trim()) .from(IICONSTRAINTS) .join(IIREF_CONSTRAINTS) .on(Iiconstraints.CONSTRAINT_NAME.equal(IirefConstraints.REF_CONSTRAINT_NAME)) .and(Iiconstraints.SCHEMA_NAME.equal(IirefConstraints.REF_SCHEMA_NAME)) .join(IICONSTRAINT_INDEXES) .on(Iiconstraints.CONSTRAINT_NAME.equal(IiconstraintIndexes.CONSTRAINT_NAME)) .and(Iiconstraints.SCHEMA_NAME.equal(IiconstraintIndexes.SCHEMA_NAME)) .join(IIINDEXES) .on(IiconstraintIndexes.INDEX_NAME.equal(Iiindexes.INDEX_NAME)) .and(IiconstraintIndexes.SCHEMA_NAME.equal(Iiindexes.INDEX_OWNER)) .join(IIINDEX_COLUMNS) .on(Iiindexes.INDEX_NAME.equal(IiindexColumns.INDEX_NAME)) .and(Iiindexes.INDEX_OWNER.equal(IiindexColumns.INDEX_OWNER)) .where(Iiconstraints.SCHEMA_NAME.equal(getSchemaName())) .and(Iiconstraints.CONSTRAINT_TYPE.equal("R")) .orderBy( IirefConstraints.REF_TABLE_NAME.asc(), IirefConstraints.REF_CONSTRAINT_NAME.asc(), IiindexColumns.KEY_SEQUENCE.asc()) .fetch(); |
Вывод
Еще раз можно сказать, что мир RDBMS очень разнороден. Абстракция базы данных в Java установлена только в определенной степени в таких технологиях, как JDBC, Hibernate / JPA и сторонних библиотеках, таких как SchemaCrawler, SchemaSpy и jooq-meta.
Ссылка: навигация по схеме базы данных на Java от нашего партнера по JCG в блоге «Java, SQL и jOOQ» .