Допустимо ли переходить между базами данных?

Question

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

Допустим, у нас есть сайт, на котором хранятся объекты разных типов. Каждый тип объекта имеет свою собственную базу данных (база данных книг и различной информации с таблицами, база данных компакт-дисков и информация с таблицами и т. Д.). Однако все объекты имеют ключевые слова, и ключевые слова должны быть одинаковыми для всех объектов, независимо от их типа. Создана новая база данных с несколькими таблицами для хранения ключевых слов, однако каждая база данных объектов отвечает за сопоставление идентификатора объекта с ключевым словом.

Это хорошая практика?

Answer 1

Есть ли причина иметь отдельные базы данных для каждого типа объекта? Вам было бы лучше использовать несколько таблиц и присоединиться к ним. Например, у вас может быть таблица GENERIC_OBJECT, в которой хранятся общие для всех типов вещи, а затем таблица с именем BOOK_OBJECT, где BOOK_OBJECT.ID = GENERIC_OBJECT.ID для данной книги. Другая таблица будет CD_OBJECT, где CD_OBJECT.ID = GENERIC_OBJECT.ID для данного CD. Тогда такие вещи, как ключевые слова, которые являются общими для всех объектов, будут храниться в таблице GENERIC_OBJECT, а вещи, характерные для элемента, будут помещаться в соответствующую таблицу элемента.

Answer 2

Разделяя их на разные базы данных, вы теряете:

• возможность выполнять ACID-транзакции (при условии, что вы не используете двухфазное решение для фиксации).
• способность иметь ссылочную целостность.
• СОЕДИНЕНИЯ по таблицам.

Answer 3

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

Answer 4

Хотя можно выполнять объединения по базам данных, я бы не стал разбивать данные по базам данных только потому, что они имеют несколько разные категории. Другие также упомянули невозможность использования ссылочной целостности в базах данных.

С другой стороны, если у каждого типа продукта радикально разные интерфейсные приложения или вы ожидаете, что каждая база данных станет очень большой, это может быть причиной рассмотрения , оставляя их в отдельных базах данных. (Хотя масштабирование не является проблемой для большинства современных баз данных).

Пример синтаксиса для объединений между базами данных:

SELECT *
FROM books b
INNER JOIN KeywordDB.dbo.Keywords k
ON b.keywordID = k.keywordID

В этом примере вы выполняете запрос из локальной базы данных, содержащей таблицу книг, и присоединяетесь к другой базе данных. (Это пример синтаксиса MS SQL)

Answer 5

Как все уже упоминали, это, как правило, не очень хорошая идея. Тем не менее, , чтобы играть в адвоката дьяволов, я видел, как другие разработчики делают это. Я уверен, что есть некоторые причины, по которым можно этого добиться, однако, если это абсолютно необходимо (не уверен, что вы запрашиваете решения, но), вы можете использовать какую-то синхронизацию для синхронизации данных. Есть все (или что нужно) данных в обеих базах данных.

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

Это может, по крайней мере, решить проблемы, которые все обрисовали в общих чертах, хотя имейте в виду, что это создает новую проблему ... Все ли синхронизировано? Удачи,
Фрэнк

Answer 6

Это кажется слишком разделенным, но с некоторыми хорошо спроектированными представлениями это может сработать, особенно если представления являются просто поисками.

Почему такое разделение вообще?

Answer 7

Нет, это плохая идея. Разделяя их на разные базы данных, вы значительно ухудшаете свою способность выполнять запросы JOIN.

Answer 8

Если решение о том, использовать одну или две базы данных, остается за вами, я рекомендую использовать только одну базу данных. Судя по вашему вопросу, данные в этих двух таблицах тесно связаны. Размер и сложность, кажется, не заслуживают разделения на две базы данных.

Какая у вас СУБД? Если это Oracle, DB2, SQL Server или даже MS Access, у вас не должно возникнуть проблем при администрировании одной базы данных с данными ключевых слов и данными объектов в логически связанных таблицах.