В моем проекте для всего используется одна БД. Я хочу разбить его на две базы данных. Статические таблицы со значениями поиска должны храниться в одной БД, а другая БД будет иметь таблицы с динамическими данными. Моя проблема в том, как мне использовать ограничение внешнего ключа между этими двумя БД. Может ли кто-нибудь помочь мне и предложить способ продолжения, лучше, если я предоставлю пример того же.
Я подумал об использовании синонимов для таблиц, а затем об ограничениях на синонимы. но позже я узнал, что синонимы нельзя использовать для обозначения ограничений.
Мне нужно поддерживать отношения между таблицами из обеих БД, поскольку проблема связана с обновлением, в новом выпуске я просто хочу обновить таблицы поиска, и для того же я хочу разделить свою БД.
Робин:
Если вы хотите физически разделить изменчивые и статические данные, я предлагаю вам взглянуть на файловые группы характерная черта. (Прокрутите страницу вниз до середины этой веб-страницы, чтобы перейти к соответствующей информации.)
Файловые группы позволяют группировать таблицы. Это позволяет вам легче контролировать их физическое местоположение (часто используемые данные могут быть размещены на быстром SSD, а другие данные могут быть размещены, например, на более медленных жестких дисках), контролировать доступ для чтения / записи (файловая группа может быть помечена как доступная только для чтения ) и улучшить схемы резервного копирования / восстановления (файловую группу можно резервировать или восстанавливать). Поскольку все таблицы находятся в одной базе данных, независимо от файловой группы, декларативная ссылочная целостность (DRI, также известная как «внешние ключи») по-прежнему работает.
Если вы настаиваете на использовании разных баз данных, вы не сможете использовать внешние ключи, и вам придется использовать другой метод. Это означает написание собственных триггеров (или, возможно, процедур). Написание собственного кода означает дополнительную работу, всегда есть вероятность ошибок в этом коде, а триггеры обычно работают хуже, чем DRI. Существуют и другие негативные аспекты использования разных баз данных, наиболее очевидно из них безопасность (вам придется управлять вдвое больше) и восстановление на определенный момент времени (труднее добиться согласованности между двумя базами данных, чем одной базой данных). Сегодня это может показаться неважным, но:
Позвольте предположить, что вы невежественны и понятия не имеете, чего хотите.
Видите ли, размер сервера sql - это проблема - либо в экспрессе, когда вы достигаете жесткого предела в 10 ГБ, либо на «реальном» сервере, когда вы нажимаете - не знаю, может быть, 10000 ГБ или около того.
По большому счету, ваше предположение неверно - вы ничего не можете, а только сложность рекламы (внешние ключи не работают, но замените их триггерами) в этом. Если это два db, то вы ничего не можете, если это два сервера, вы добавляете задержку и массу других проблем.
Я бы начал с предположения, что предъявленное вами требование недействительно. Почему вы думаете, что это нужно?
У меня дома есть база данных размером почти 1000 ГБ и никаких проблем с размером.