Как перестать делать одно и то же

[worldmind]

приходилось прописывать все джойны между таблицами ручками. И это притом, что в 90% случаев поля и условия соединения таблиц совпадали от запроса к запросу

view?

[StrangerInTheKy]

Увы мне, боярин.
Допустим, есть пять таблиц, связанных друг с другом. В одном запросе данные нужны из 1 и 2, в другом — из 3, 4 и 5, а потом из всех вместе. И так далее. Слишком много комбинаций.

[cross_join]

QBE?

[Zondoo]

Потом пилить автоподбор нужной вьюхи придется)
А если серьезно, то все дополнительно осложняется двухуровневым партиционированием части сущностей — сложно сделать оптимизированную вьюху, при этом удобную всем

[asmm]

в них редко заводятся unique constraint и foreign key в целях повышения производительности, а без этого программе не узнать, как между собой связаны сущности и что она может тебе предложить

Не знаю как в других базах, но в Oracle ключи можно создать и сделать их DISABLED

[Zondoo]

Я об этом тоже думал! Согласен, классный был бы вариант. Пробовал такое сделать в песочнице, но тема не взлетела. Хотя возможно просто не хватило навыков админа

[asmm]

А в чё проблема?

ALTER TABLE products
ADD CONSTRAINT products_supplier_fk
  FOREIGN KEY (supplier_id)
  REFERENCES supplier(id)
;
ALTER TABLE products
DISABLE products_supplier_fk
   constraint_name
;

А потом SELECT из DBA_CONSTRAINTS для составления правильных соединений

Вот доки:
docs.oracle.com/cd/B28359_01/server.111/b28310/general005.htm#ADMIN11537

Только что узнал что оказывается raise CONSTRAINT'ов можно направлять в таблицы!
Типа:

ALTER TABLE dept ENABLE PRIMARY KEY EXCEPTIONS INTO EXCEPTIONS;

а потом при возникновении исключения делать селекты и выдавать человеческие ошибки, какие строки вывалились в исключения:

SELECT * FROM EXCEPTIONS;
fROWID               OWNER      TABLE_NAME      CONSTRAINT
------------------  ---------  --------------  -----------
AAAAZ9AABAAABvqAAB  SCOTT      DEPT            SYS_C00610 
AAAAZ9AABAAABvqAAG  SCOTT      DEPT            SYS_C00610 

SELECT deptno, dname, loc FROM dept, EXCEPTIONS
    WHERE EXCEPTIONS.constraint = 'SYS_C00610'
    AND dept.rowid = EXCEPTIONS.row_id;

DEPTNO     DNAME             LOC
---------- --------------    -----------
10         ACCOUNTING        NEW YORK
10         RESEARCH          DALLAS

[asmm]

И кстати, насчёт отказа от внешних ключей, крайне плохая идея: издержки мизерные, проблем много. Вот тут Кайт приводит размышления с тестами:
Эффективное проектирование приложений Oracle / Это база данных, а не свалка данных
www.rsdn.org/article/db/goodoraapp.xml#EZTAE

В последней задаче я как раз оптимизировал загрузку данных в БД, средняя нагрузка ~300-400 записей в секунду + ключи/индексы + триггеры + бизнес-логика
с такой нагрузкой база иногда не справлялась
удалось довести до скорости обработки 50000 записей за 6-7сек, все ключи, индексы и бизнес-логика осталась, при отключении БЛ, 50000 записей залетало за 0,7 сек в целевую таблицу с ключами и индексами.
Oracle хорошо умеет массово обрабатывать данные. Обычно проблема производительности в этом и заключается, что этим не пользуются.

[cerbernar]

Поясните, пожалуйста, чем xml лучше json при редактировании метаданных.

[Zondoo]

метаданные предполагалось редактировать вручную большому количеству аналитиков. Чем более читаемым окажется формат, тем меньше вероятности допустить ошибку редактирования и сделать файл невалидным.
Для наглядности можно зайти на какой-нибудь online конвертер и сравнить в два формата. Я решил, что количество скобок json неподготовленного пользователя может запутать.