О разработке структуры базы данных (для начинающих) (обсуждение статьи)

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

3

Сообщение от taijet Много что делать удобно, если ввод/просмотр данных делать через таблицу. А меня тут учат: ввод данных делать через формы. Кстати форм у вас в базе тоже нет. Я пытаюсь вложить в свою голову правильные принципы, вот и пытаюсь не сбиться с пути.

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

0

Сообщение от alvk В твоём варианте может быть разная специальность у студента и его группы.

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

0

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

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

0

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

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

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

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

3

Сообщение от iifat Рискну добавить как общий совет: никогда -- НИКОГДА -- не делайте осмысленную информацию первичным ключом

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

0

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

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

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

Добавлено через 7 минут

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

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

Сообщение от minob А в случае сохранения записи с отсутствующим обязательным атрибутом не меньший наплыв радости ощутит человек, распечатавший многостраничный отчет по этим данным.

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

Добавлено через 14 минут

Сообщение от Pelena А если в одном поле записаны Фамилия Имя Отчество? Я всегда думала, что это тоже не соответствует 1НФ

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

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

0