@Ameli

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

3

@Андрэич

Правильно учат. Это так же верно, как и то, что на Солнце легче смотреть через темные очки

0

@Ameli

с чего ты взял? оО конечно одинаковая. это дублирование специальности для удобства выбора. Обычно дублирование - это плохо, в этом случае это хорошо. Это мое мнение

0

iifat

Рискну добавить как общий совет: никогда -- НИКОГДА -- не делайте осмысленную информацию первичным ключом и, соответственно, полем связи, как в приведённом примере, где, как я понимаю, предлагается идентифицировать группу -- номером, студента -- номером зачотки, а преподавателя -- табельным номером. Иначе для вас станут весьма неприятным открытием случаи смены зачотки из-за потери или смены фамилии, глобальные перенумерования групп или табельных номеров. Нету у нас ничего постоянного и уникального кроме генетического кода, который также не стоит делать первичным ключом -- тупо из-за размера...

И ещё: не стоит увлекаться контролем правильности на уровне структуры базы. Радость оператора, введшего пятьдесят атрибутов и обнаружевшего, что пятьдесят первый ему забыли сообщить, из-за чего он не может сохранить введённое, не знает границ...

0

@minob

В интернете можно найти множество хроник боев в "священной войне" суррогатные vs естественные ключи, не приносящих победу ни одной из сторон. Каждая сторона остается при своих убеждениях. Поэтому думаю не стоит затевать еще один холивар.
А в случае сохранения записи с отсутствующим обязательным атрибутом не меньший наплыв радости ощутит человек, распечатавший многостраничный отчет по этим данным.

3

@alvk

Здесь таких ключей нет. Вы с темой ошиблись.

0

iifat

Мы? Ошиблись? Невозможно!

Таки что тогда первичные ключи у перечисленных (студент, преподаватель, группа)?

Добавлено через 7 минут
Спасибо. Почёл парочку. Ей богу, не хочу холиваров, но, как я понял, против приёма в принципе -- никто не возражает. Применять с умом -- да. Не панацея -- да. Однозначно глупо вводить в таблицу, например, связей m:n -- естественно. И тем не менее, в статью для начинающих, имхо, стоит добавить, с парочкой плюсов и минусов.

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

Добавлено через 14 минут
Вроде уже подробно рассмотрели, всё ж добавлю на всякий случай.

Что простое поле, а что составное -- определяется задачей. Вполне могу себе представить задачу, для которой не требуется делить ФИО на составляющие -- тогда это простое поле; а вот, например, если предполагается обмен с банком -- тут уж просто непременно делить на три, иначе рано или поздно появится какой-нибудь Пак Сун Чо -- при чём вполне может оказаться как Сун Чо без отчества, так и Сун, по отчеству Чо -- а для банка это принципиальная разница. Да и инициалы ему автоматом попробуй-ка подбери...

0