Это мой первый пост здесь, и я старался делать домашнее задание.
Мне нужен лучший способ разработки баз данных хранилища данных для Postgres, чем использование Power * Architect. Вот полная печальная история:
Я занимаюсь разработкой хранилищ данных, в основном на бесплатных / открытых платформах (Linux + Postgres). Все таблицы, которые я создаю, не имеют между ними никакого отношения, потому что в средах DW принудительное применение FK практически не приносит никакой пользы. Это потому, что я полностью контролирую то, что входит в таблицы. Кроме того, при обслуживании (например, обновлении или удалении неправильных строк) эти ограничения добавят дополнительной работы, поэтому я их не использую.
Чтобы смоделировать эту базу данных DW, я должен рисовать диаграммы, и рекомендуется показать, какая таблица к какой относится через внешний ключ / первичный ключ. Увидеть взаимосвязь помогает коммуникация модели с клиентом, а также ее развитие.
Однако большинство разработчиков моделей баз данных, например Power Architect, генерируют код для фактического создания ограничений. Кроме самого изменения кода Power Architect, невозможно помешать ему это сделать.
И вот тут-то и возникает проблема: когда я начинаю развивать модель, всякий раз, когда я проверяю текущую базу данных (которая полностью свободна от взаимосвязей) с моей моделью (которая полна линий взаимосвязей FK), чтобы найти то, что (таблицы, столбцы, индексы), Power * Architect жалуется, что связи отсутствуют, и «любезно» генерирует код для их создания. Мне нужно прочитать diff, выполняя большую фильтрацию разума (пытаясь прочитать код, не принимая команды ограничения добавления), и, применяя diff'd SQL к моей базе данных, я должен вручную удалить эти команды.
Это не было бы проблемой, если бы, как в Oracle, я мог бы приказать Postgres отключить ограничения отношений. Я мог хранить аккуратные диаграммы в Power * Architect, не беспокоясь о действующих в базе данных взаимосвязях. Но я не могу (и никогда не собираюсь переходить на Oracle). Так что моя проблема была бы решена, если бы я мог постоянно оставлять эти ограничения, ЕСЛИ это не сильно ухудшает запросы к базе данных. Я могу иметь дело с некоторой потерей производительности при записи, если она колеблется около или ниже 10% (например, INSERT принимает 1'06 "вместо 1'00").
Итак, вопросы:
«Есть ли какие-либо существенные потери производительности при выполнении большого объема записи, некоторых небольших обновлений и удалений в таблицах Postgres с действующим ограничением связи FK?»
Согласно этим сообщениям, улучшает ли внешний ключ производительность запросов? и http://www.experts-exchange.com/Database/MS-SQL-Server/A_4293-Can-Foreign-key-improve-performance.html, MS SQL Server страдает от снижения производительности при записи и может немного повысить производительность при чтении . Это общее правило? Постгрес ведет себя аналогичным образом? Я осмотрелся и не нашел на него прямого ответа. Этот ответ https://stackoverflow.com/a/83527/3507015 комментирует флаг НЕТ ДЕЙСТВИЙ. Будет ли это работать (я имею в виду, поддерживать отношения без ущерба для производительности)? (У Postgres есть эта опция, но согласно http://www.postgresql.org/docs/8.1/static/ddl-constraints.html, похоже, он не выполняет «никаких действий», но вместо этого не позволяет выполнять какие-либо действия.)
Конечно, было бы лучше иметь дизайнера базы данных с теми же функциями Power * Architect (обратное / прямое проектирование базы данных, сравнение баз данных / моделей и т. Д.), Которые позволяли мне рисовать линии, но не требовать, чтобы они фактически создавались как ограничения, которые я не пробовал. создавать его каждый раз, когда я сравнивал модель с базой данных.
Извините, что в посте слишком длинный, чтобы задать один-единственный вопрос.
