SQL Server копирует данные между базами данных

Я использую SQL Server 2019. У меня есть база данных MasterDB, которая доступна для приложения с графическим интерфейсом. У меня также будет до 40 пользовательских баз данных, таких как User1DB, User2DB и т. д. И все эти пользовательские базы данных будут иметь одну и ту же схему и таблицы.

У меня есть требование скопировать данные таблиц (перезаписать цель) из одной пользовательской базы данных (скажем, User1DB) в другую (скажем, User2DB). Мне нужно сделать это из базы данных MasterDB, поскольку клиентское приложение с графическим интерфейсом будет иметь доступ только к этой базе данных. Как справиться с этой динамичной ситуацией? Я бы предпочел статический SQL (в форме хранимых процедур), а не динамический SQL.

Любое предложение будет высоко оценено. Спасибо.


sql-server cross-database
person DataPy    schedule 28.01.2021    source источник
comment
Звучит как ужасный дизайн? Почему вы создаете отдельную базу данных для каждого пользователя? Однако, если вам нужно, что конкретно вы не понимаете? удалить, а затем вставить?   -  person Dale K    schedule 29.01.2021
comment
Дейл К., нам нужны исходные данные управления — подумайте, когда вы клонируете репозиторий git, вы получаете специфичную для пользователя/децентрализованную полную ветку с историями и т. д.   -  person DataPy    schedule 29.01.2021
comment
Но почему бы не управлять исходным кодом с помощью одной базы данных со столбцом идентификатора пользователя в соответствующих записях?   -  person Dale K    schedule 29.01.2021
comment
В конце концов, вы обнаружите, что создаете для себя в 40 раз больше работы, если идете по этому пути. если вам нужно получить данные управления источником, создайте несколько управляющих таблиц, которые позволяют пользователю извлекать или блокировать данные, а также сохранять историю изменений аудита. Подумайте об этом: если пользователь подключается к главной базе данных, как вы узнаете, какой пользователь? какая БД будет содержать данные этих пользователей? и если вы разрешите доступ только к masterdb, будет ли у вас сквозное представление или SP для каждого пользователя? 40-кратное увеличение объектов только для управления некоторыми данными?   -  person Jeremy    schedule 29.01.2021
comment
Я немного запутался с вашим дизайном. Как user получит доступ к User1DB или User2DB, если графический интерфейс имеет доступ только к MasterDB?   -  person Squirrel    schedule 29.01.2021
comment
Ребята (Dale K, Jrermy, Squirrel и spencer741), большое спасибо за ваши отзывы. Это что-то новое, что мы разрабатываем, и я принял как должное некоторые предположения. Я подправлю свои дизайнерские идеи и посмотрю, как я могу сделать все это в одной базе данных... еще раз спасибо.   -  person DataPy    schedule 29.01.2021

Ответы (1)


arrow_upward
0
arrow_downward

Ознакомьтесь с этим вопросом здесь для передачи данных из одной базы данных в Другая.

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

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

Итак, если наши предположения верны, вам просто нужно иметь пользовательскую таблицу, где могут быть ваши поля...

UserTable
UserId
FName
LName
EmailAddress
...

Изменить: я вижу в комментариях, что вы имеете в виду данные системы управления версиями... Я предлагаю вам изучить базы данных и то, как они должны быть спроектированы, реализованы и как данные должны передаваться. Есть масса отличных статей и книг по этому поводу с помощью простого поиска в Google.

Если вы хотите реплицировать свои данные для целей резервного копирования, ознакомьтесь с некоторыми принципами проектирования хранилища данных, возможно, для этого будет создано отдельное хранилище данных в другом географическом регионе. Последнее - очень сложная тема, на которую я не могу остановиться в этом ответе, но похоже, что это выходит далеко за рамки ваших текущих потребностей. Мое предложение состоит в том, чтобы вернуться назад и уточнить потребности вашего приложения, понимая при этом некоторые основы баз данных (или различных методов хранения данных). Реализуйте что-то, а затем посмотрите, где это можно расширить/рефакторить.

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

person spencer741    schedule 28.01.2021