Основные отношения (основной ключ, внешний ключ) в SQL Server Management Studio

Question

Почему мы определяем ключевые отношения в SQL Management Studio ?. Я студент, и учитель хотел этого. На самом деле я думаю, что это не обязательно, потому что я могу подключать таблицы с sql-запросами. Например: У нас есть EMPLOYEE и MANAGER Таблица. EMPLOYEE имеет ID, Name, SuperID(supervisorID in MANAGER) MANAGER имеет ID, Name В учитель фактически сказал, что «вы должны соединить две таблицы в среде SQL Server Management для работника SuperID является внешним ключом MANAGER«s ID и» я могу подключиться (то есть я могу видеть связь две таблицы) две таблицы с SQL запросом, как:

SELECT e.*,m.Name as 'Manager's Name' FROM EMPLOYEE e, MANAGER m 
WHERE e.SuperTC = m.TC 

это нормально, но почему мы соединим две таблицы в SQL Management Studio (Первичный ключ, внешний ключ в разделе SQL Management Studio) Если мы не будем? подключиться, что будет? Нужно ли, когда мы работаем в профессиональной компании?

Answer 1

Для обеспечения ссылочной целостности и предотвращения потерянных записей. Он сообщает базе данных, что ей нужно знать, чтобы было невозможно сохранить данные, которые недействительны в соответствии с вашими бизнес-правилами. Если вы не сможете хранить недопустимые данные, ваши данные будут действительны. Действительные данные делают всех счастливыми.

• Если каждый EMPLOYEE должен иметь MANAGER, то скажите базу данных, что и это не позволит вам создать EMPLOYEE запись без MANAGER ссылки.

• Если а MANAGER потребность быть удалена, но вы по-прежнему есть EMPLOYEE, который перечисляет, что идентификатор как MANAGER, база данных не позволит вам удалить MANAGER (или можно сказать также удалить EMPLOYEE с каскадным удалением) ,

• Если необходимо изменить ключ MANAGER, каскадное правило обновления для внешнего ключа автоматически автоматически обновит любые связанные записи EMPLOYEE.

Если мы не будем подключать то, что будет происходить?

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

Что-то, о чем многие разработчики не думают: даже если вы только лицензируете приложение для своих клиентов, и у вас все еще будет свое приложение, клиент владеет данными. Это их данные во всех смыслах. Ваши права как независимого поставщика заканчиваются авторскими правами и патентами на программный код. Если клиент хочет подключиться к РСУБД, у них есть лицензия на свой собственный сервер, чтобы читать данные, которыми они владеют, то есть их право, и они абсолютно это сделают. Это не обратная инженерия. Действительно, эта возможность является одной из основных и явных целей использования общей СУБД, и это одна из причин, почему клиенты любят их. Они всегда могут получить свои данные.Клиенты do не хотят гигантские информационные силосы, которые мешают им перемещать данные туда, где они в ней нуждаются. Каким бы ни было приложение, которое вы продали, почти наверняка будет не делать все, что нужно бизнесу. У них будет несколько приложений, и все они должны общаться, чтобы работать вместе.

Answer 2

Да, это необходимо при посещении профи. Фактически, когда вы указываете поле внешнего ключа в таблице, которое относится к первичному ключу к другому, это поле будет индексироваться. И индексы в SQL Server демонстрируют большой прирост производительности. Индексы в SQL Server улучшат производительность для SQL Server Engine. Добавление индексов походит на то, что ваши значения полей вписываются в dictionnary, и все мы знаем, что найти слово в dictionnary намного проще, чем найти его в списке неупорядоченных слов. Производительность не примечательна для небольших данных, но она будет необходима для больших данных, поэтому при переходе на профессионалы внешние ключи будут необходимы, поскольку мы имеем дело с крупномасштабными базами данных. Ссылочная целостность - вторая причина, потому что ваши таблицы базы данных представляют собой конкретное представление определенного дизайна, предназначенного для сохранения целостности данных. Если вы что-то создаете, и вы не ставите его на место, почему мы будем создавать базы данных? С внешними ключами вы уверены, что ваш дизайн соответствует реализации ваших таблиц.