SQL-внешний ключ между проектами в разных решениях VS

Question

Я хочу разделить разработку нашего решения хранилища данных на управляемые проекты Visual Studio, которые можно редактировать независимо и расти органично. Я разработал проект, который содержит все соответствующие размеры, такие как Date в одном решении. Могу ли я ссылаться на свое измерение Date из другого решения, где мне нужно включить внешний ключ? Я попытался ссылаться на dacpac, содержащий согласованное измерение, но это не работает должным образом.

Answer 1

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

Вы можете использовать триггеры для управления FK, что, конечно же, не лучшее решение.

Ограничения FOREIGN KEY могут ссылаться только на таблицы в одной базе данных на одном сервере. Перекрестная база данных должна быть реализована через триггеры. Для получения дополнительной информации см. CREATE TRIGGER (Transact-SQL).

https://msdn.microsoft.com/en-us/library/ms189049.aspx

---

Основываясь на ваш комментарий (см ниже), вот некоторые мысли:

У вас есть несколько хороших аргументов. Хотя я искал способ, которым мы могли бы моделировать несколько бизнес-процессов параллельно, это не вариант. Похоже, что единственным вариантом может быть один большой проект, а затем обрабатывать как управлять более чем один разработчик, работающий в растворе, в то же время - благодаря

• Одна база данных = один проект
• Принудительно связи между членами команды
• Обновите свою политику VCS, чтобы свести к минимуму проблемы
• Обучать член команды о возможных проблемах и их обходные
• • Включая вариант развертывания
• Обеспечить достаточные ресурсы (в том числе Девых рабочих станций) и использовать локальные экземпляры для разработки
• Построения среды SIT (интеграция), где вы можете проверить изменения и как они ведут себя во время развертывания.
• Создайте общую среду DEV, которая используется для объединения работы членов вашей команды.
• Commit/push файлы в CVS, которые считаются выполненными. Commit/push регулярно
• Маршрутные задачи для минимизации конфликтов (если член команды имеет какое-то отношение к объекту A, попробуйте направлять все задачи, связанные с объектом A, этому разработчику или отложить второе изменение до тех пор, пока не будет выполнено первое)
• Если вы используете dacpac для развертывания, включите файл конфигурации (протестированный в SIT env) рядом с файлом dacpac. (SIT должен отражать производственную среду при тестировании развертывания)

И снова: Обеспечить связь внутри и снаружи команды. Это ключ.

Answer 2

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

Есть несколько вещей, чтобы быть осторожным здесь:

• Ссылка должна быть типа «Тот же базы данных»
• Ссылка должна быть в направлении Факт -> Dimension
• При развертывании проекта «Факт» вы должны обязательно указать опцию «Включение составных объектов». Это значение по умолчанию в Visual Studio.
• Циркулярные ссылки не допускаются. Если у вас есть обходной путь (очень кратко, google для большего), это создать «родительский» проект со ссылками на обе стороны «круга».

Это также возможно создать внешний ключ для ссылочного dacpac, а не проекта базы данных. Опять ссылка должна быть в направлении Факт -> Измерение. Вам также нужно будет подумать над процессом сборки, так как в действительности вы принимаете двоичную зависимость от от «dacpac» Dimensions. Вы также можете добавить dacpac в проект ссылки (я, как правило, создаю папку для них), поэтому он попадает туда же в исходное управление).

В случае это помогает, я создал решение, которое демонстрирует оба метода и разделяю его здесь: https://github.com/arapaima-uk/FKsToReferencedDacpacs