Это довольно распространенный вопрос, и лучший способ справиться с этим - задать себе следующий вопрос:
Нужно ли мне когда-нибудь повторно использовать эти данные в другом приложении?
Если ответ «да», то вам определенно следует составить таблицу так, чтобы она была отделена от фактического приложения. Позвольте привести пример. Предположим, вы будете писать приложение для регистрации билетов службы поддержки для сотрудников вашей компании. Вы заметите, что сотрудники уже хранятся в общей базе данных AcmeEmployees.
Ваша цель как программиста / dba - избегать дублирования, администрирования и опечаток. Таким образом, вы хотите управлять данными только один раз. Для вашего приложения службы поддержки имеет смысл повторно использовать информацию о сотрудниках, которая хранится в другой базе данных.
Если вы пишете хранимую процедуру и хотите получить доступ к данным сотрудника, вы просто делаете:
SELECT EmpFullName FROM AcmeEmployees.dbo.Employees
То есть databaseName.ownder.tableName. Так что да, проектируйте с учетом того, что вы хотите повторно использовать общие данные. Вот несколько преимуществ для этого:
- Вставки / обновления выполняются один раз и только один раз
- Мало или нет типографских ошибок (если все сделано правильно, если вам не о чем беспокоиться)
- Любые изменения в исходных данных автоматически отображаются во всем вашем домене (все приложения, использующие эти общие данные)
- Возможность многократного использования означает меньше людей, выполняющих работу канцелярского типа, и больше времени для изучения других проблем.
- Такие поля, как Статус, могут влиять на приложение, например, в системе справочной службы, о которой я упоминал выше, если сотрудник решит покинуть компанию, указав, что сотрудник = неактивно, что сотрудник больше не сможет регистрировать билеты в службе поддержки. система. Это хороший способ уберечь старые данные от новых систем
- И самый лучший, это просто имеет смысл , на моем рабочем месте у нас так много разных приложений, но приятно то, что у нас есть набор общих таблиц данных. Одним из них являются сотрудники. Я бы ненавидел это, если бы нам пришлось заново создавать сотрудника и устанавливать имя, фамилию, отчество и т. Д. Каждый раз, когда мы получаем нового сотрудника, и нам нужно было вставлять этого сотрудника в каждое приложение.
Давайте продолжим с примером нашего сотрудника. HR теперь является главным отделом обновления или вставки информации о сотрудниках. Затем я могу повторно использовать эту таблицу, чтобы создать не только мою систему отслеживания службы поддержки, но и сказать, что менеджеру нужен организационный график. Ему / ей нужна какая-то организационная иерархия, в которой перечислены менеджеры и сотрудники, которые отчитываются перед своими менеджерами. Хорошо, что вы думаете, у вас есть общая таблица базы данных «Сотрудники», в которой есть такие поля, как EmployeeName, Status, ManagerID. Затем вы можете быстро создать организацию. приложение диаграммы, использующее те же самые общие данные:
SELECT ManagerID as TheManager, EmployeeName
FROM Employee
WHERE Status='Active'
AND ManagerID="SomeManagerID"
Теперь у вас есть набор сотрудников, подчиняющихся менеджеру, и вы можете построить иерархию на основе этого. Ну, в чем смысл этого второго примера, вы можете спросить. Это означает, что ваша разработка становится НАМНОГО БЫСТРЕЕ . Вы перестаете беспокоиться о разработке другой базы данных и повторно используете то, что является общим и доступным для вас. Это ускоряет развитие!