Обновить
Комментарии 27
Ну, еще бы упомянули слово «нормализация», чтобы общаться с теми, кто по более классическим мануалам учился и будет замечательно :)

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

А потом расскажем, зачем БД индексы, расскажем про SQL, оговоримся про noSQL и перестанем укладываться в два часа :)

Был в жизни случай, когда надо было заочникам материал всего семестра упихать в голову за три часа. Вы справились лучше :)
У меня тоже были такие случаи, и это в любом случае mission impossible. Поэтому да, тут проще описать то, что упомянуто, чем то, что не упомянуто. Ну так и я — только начал учебник писать :).
Мое мнение: можно (и нужно — ибо необъятное объять нельзя) ограничиться только тем, что упомянуто.
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
Спасибо, я подумаю об этом. Я в первую очередь думал о тех, кто только начинает потому что те, кто уже изучил нормальные формы испорчены безвозвратно, а их отсылка к страшным терминам будет только пугать (ну и отвлекать, если они пойдут читать их в википедию). В любом случае, у меня же нормальный курс, там есть дальше и определения, и нормальные формы. Я ещё не настолько радикализовался, чтобы нормальные формы совсем выбрасывать :)
>Дублирование данных не несёт информации
Ну, не совсем. В реальной жизни бывают такие таблицы, в которых дублирование это нормально. Просто потому, что когда вы разрабатываете что-то в рамках СУБД, то таблицы — это единственная структура данных, которая у вас есть, и поэтому скажем логи (аудит) — это тоже таблица, но без уникального ключа. Немного странно и не по книжкам, но бывает.
Вы же сами понимаете, что тут «ну, не совсем» можно приписать практически к каждому абзацу :). Если раскрывать, что именно «не совсем», туториала не получится. Small moves, Ellie, small moves.
Не, это была не претензия. Мне пост как раз очень понравился, понятно, что идеал бывает редко, но в целом — то что надо. Как раз показана нормализация как инструмент, а не как какая-то самоцель, которой непременно нужно достичь непонятно зачем.

А это было просто небольшое уточнение.

А еще оно служит целям резервирования и позволяет заметить несоответствия в веденных данных. Потому что если полностью удалить дублирование, то стоит в 'Персона' заменить (или изначально ввести неправильно) 'Том Хэнкс' на 'Иван Иванович' — и бедный Том Хэнкс больше никогда никому не докажет, что он вообще когда-то существовал.

>если полностью удалить дублирование
Это да. К сожалению многие статьи на эту тему страдают как раз тем, что предлагают его всегда и полностью удалить, даже тогда, когда это вредно.
Статья отличная!
Проблема
Сеанс один, а места из разных залов.

Решения без триггеров навскидку не придумал, а можете огласить? Под спойлер, или в личку, если есть возможность.
Есть решение, которое можно попробовать покрутить — билет продавать не на сеансы, а на место в сеансе, дополнительным бонусом получаем возможность навести порядок с ценами — мне вообще не нравиться цена в фильме, а потом еще и цена за место.
Если крутить дальше, то выходим на новую табличку, назовем ее Место-в-сеансе (ИД, МестоИД, СеансИД, Цена), тут уже можно навести лад и с ценой — от фильма и типа места.
Всегда считал, что основная задача реляционных БД — все же эффективное хранение и выборка данных, а не их валидация.
Практика показывает, что валидации много не бывает.
Одно из главных задач реляционных БД это сохранение целостности и непротиворечивости данных.
Вариантов хранения без поддержания данных требований и так достаточно)
Но это на мой взгляд
Проблема: в таблице билетов нет проверки зала сеанса соответствующему залу в таблице мест.
Реляционное решение есть, но с добавлением избыточности и использованием новых ключей (добавленные элементы выделены синим цветом).
image
Реляционное решение есть, но с добавлением избыточности

В данном случае не надо бояться избыточности. Решение хорошее и правильное. Для таких типов ключей есть своё название: суперключ. Это ключ, который включает в себя ID и ещё некоторые добавочные поля.
Статья топовая)
Вы прям великолепно расписали. Обязательно буду кидаться ей в студентов.
Э-э-э. Блеск и нищета РМД (СУРБД в частности).
Нужно было сделать БД по продаже билетов, а пришлось строить ещё БД фильмов, БД людей.
И это ещё не глубоко копнули. :-)
Спасибо за статью. Отправил своему студентику, которого я пытаюсь курировать. А можно что-то подобное по noSQL? Я бы сам почитал. Сколько раз не пытался разобраться с noSQL (уже 3 «проекта» на них сделал) — там либо всё-равно применяю принципы реляционности, либо бардак и дублирование, от которого у меня бомбит.

Я не смогу. Я могу объяснять только то, что сам понимаю и что в голове в систему уложено.

Вы сделали отличный материал «на пальцах»! Спасибо.
Тоже преподаю, но школьникам. БД упоминаем «для знакомства». А с вашим материалом теперь можно и задачки на размышление дать.

Статья — хороший пример большого недостатка РМД — многовариантность построения структур БД, что превращает эту задачу в вид искусства.

Не могу согласиться. Это не входит в рамки статьи, но если описать информационные сущности, их ключи и связи, структуру бд можно строить автоматически, потому что вариативности не остаётся. Разработать инфомодель, то есть описать предметную область — вот это ближе к искусству. Но к бд это отношения не имеет.

Вы заблуждаетесь. Структуру БД «автоматически» «построить» невозможно, необходимо ДУМАТЬ. К сожалению, нет возможности объяснить это коротко.
Спасибо, за статью. Как заново родился!
Пожалуйста, продолжайте этот цикл. Про триггеры там и все такое очень хочется услышать в вашем изложении.

Спасибо за статью! Я как раз пишу приложение для миникинотетра)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.