2016-12-16 3 views
-1

У меня вопрос о проектировании базы данных.О проектировании базы данных

Какой из них лучше подходит для относительно большой системы баз данных;

Design1 enter image description here

design2 enter image description here

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

Что вы думаете?

+0

Измените свой вопрос, чтобы объяснить, как мы должны читать вторую диаграмму. – philipxy

+0

@philipxy Я думаю, что диаграммы очень четкие. Во-первых, мы храним телефонные номера студентов в другой таблице, а во втором мы храним телефонные номера студентов в одной таблице с использованием XML. –

ответ

3

Ничего. Что делать, если двое учеников живут в общежитии и имеют (разделяют) один и тот же номер телефона (общежитие) или являются родными и близкими, живущими дома? таблица телефонных номеров должна быть составной клавишей с phonenumber, иstudentId в качестве составного первичного ключа. Это отражает то, что называется многими-ко-многим, или ассоциативные отношения, которые не могут быть легко представлены в XML.

В приведенной ниже схеме предполагается, что каждый учащийся определяет «тип» телефона, для которого он использует эту линию. если тип телефона определяется только телефоном, то вы добавили бы другую отдельную таблицу для имен телефонов и телефонов, без studentId, и сделайте поле phoneNumber в ассоциативной таблице внешним ключом (FK) на этот новый телефон таблица

enter image description here

+0

Спасибо за ваш ответ, я объясню вашу коррекцию. Но это не тот ответ, который я ищу, что я хочу узнать: «Какой подход более полезен, отношения или XML?» Еще раз спасибо. –

+0

ahhhh, если это все, что вас интересует, то реляционным является ответ. Вы не можете легко выполнять отношения «многие ко многим» в XML. –

0

Я бы с Design 1, но с модификацией. Однако таблица телефонных номеров имела бы идентификатор студента в качестве первичного ключа. Таким образом, у вас может быть более одного ученика, использующего тот же телефон, что для меня вполне нормальный сценарий.

+0

Спасибо за ваш ответ, я рассмотрю ваше предупреждение. –

+0

Если таблица номеров телефонов имеет «studentId» в качестве Первичного ключа, то для каждого ученика может быть только одна запись. Нет, должен быть основной ключ COMPOSITE, на 'studentId' и' phoneNumber'. –

0

Я бы не стал обманывать это, нормализуя номера телефонов до некоторого потенциально бесконечного списка.

Сколько или каких номеров вы действительно нуждаетесь в студенте? Например, вам нужен номер факса для них? Может быть вам нужен срок и несрочный номер времени?

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

+0

Чем вы за ваш ответ. Но я заметил, что все вы, ребята, одержимы моим маленьким студенческим примером, я разработал эту базу данных только для «примера». Я действительно хочу узнать, что использование XML - это плохая практика для разработки баз данных. –

+0

@OnurEryilmaz Мы можем только ответить на вопрос, который вы просили, и характеризуя людей, которые нашли время, чтобы помочь как «одержимый» довольно грубо. Вы должны были спросить: «Использует ли XML плохую практику для разработки баз данных?» Или, еще лучше, ссылается на любой из существующих вопросов по этой теме. –

+0

Прошу прощения за мой язык, я не думал, что «одержимый» груб. Но, как я прошу в моем вопросе «какой смысл», лучше. Я не спросил: «Является ли моя первая диаграмма неправильной?». Но снова мне жаль. –

Смежные вопросы