Comments 27
Ну, еще бы упомянули слово «нормализация», чтобы общаться с теми, кто по более классическим мануалам учился и будет замечательно :)
А чтобы пройти собеседование с меньшим позором — еще и добавить про отношения один-ко-многим, многие-ко-многим, один-к-одному, тогда статья станет почти эталонной :)
А потом расскажем, зачем БД индексы, расскажем про SQL, оговоримся про noSQL и перестанем укладываться в два часа :)
Был в жизни случай, когда надо было заочникам материал всего семестра упихать в голову за три часа. Вы справились лучше :)
А чтобы пройти собеседование с меньшим позором — еще и добавить про отношения один-ко-многим, многие-ко-многим, один-к-одному, тогда статья станет почти эталонной :)
А потом расскажем, зачем БД индексы, расскажем про SQL, оговоримся про noSQL и перестанем укладываться в два часа :)
Был в жизни случай, когда надо было заочникам материал всего семестра упихать в голову за три часа. Вы справились лучше :)
У меня тоже были такие случаи, и это в любом случае mission impossible. Поэтому да, тут проще описать то, что упомянуто, чем то, что не упомянуто. Ну так и я — только начал учебник писать :).
Мое мнение: можно (и нужно — ибо необъятное объять нельзя) ограничиться только тем, что упомянуто.
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
Но я бы ещё после каждого разобранного понятия написал, как оно называется в больших и скучных учебниках — чтобы прокинуть мостик к этим учебникам, чтобы говорить с людьми, которые по ним учились, на одном языке, чтобы слова типа «третья нормальная форма» не ставили в тупик на собеседовании.
Спасибо, я подумаю об этом. Я в первую очередь думал о тех, кто только начинает потому что те, кто уже изучил нормальные формы испорчены безвозвратно, а их отсылка к страшным терминам будет только пугать (ну и отвлекать, если они пойдут читать их в википедию). В любом случае, у меня же нормальный курс, там есть дальше и определения, и нормальные формы. Я ещё не настолько радикализовался, чтобы нормальные формы совсем выбрасывать :)
+1
>Дублирование данных не несёт информации
Ну, не совсем. В реальной жизни бывают такие таблицы, в которых дублирование это нормально. Просто потому, что когда вы разрабатываете что-то в рамках СУБД, то таблицы — это единственная структура данных, которая у вас есть, и поэтому скажем логи (аудит) — это тоже таблица, но без уникального ключа. Немного странно и не по книжкам, но бывает.
Ну, не совсем. В реальной жизни бывают такие таблицы, в которых дублирование это нормально. Просто потому, что когда вы разрабатываете что-то в рамках СУБД, то таблицы — это единственная структура данных, которая у вас есть, и поэтому скажем логи (аудит) — это тоже таблица, но без уникального ключа. Немного странно и не по книжкам, но бывает.
Вы же сами понимаете, что тут «ну, не совсем» можно приписать практически к каждому абзацу :). Если раскрывать, что именно «не совсем», туториала не получится. Small moves, Ellie, small moves.
А еще оно служит целям резервирования и позволяет заметить несоответствия в веденных данных. Потому что если полностью удалить дублирование, то стоит в 'Персона' заменить (или изначально ввести неправильно) 'Том Хэнкс' на 'Иван Иванович' — и бедный Том Хэнкс больше никогда никому не докажет, что он вообще когда-то существовал.
UFO just landed and posted this here
Есть решение, которое можно попробовать покрутить — билет продавать не на сеансы, а на место в сеансе, дополнительным бонусом получаем возможность навести порядок с ценами — мне вообще не нравиться цена в фильме, а потом еще и цена за место.
Если крутить дальше, то выходим на новую табличку, назовем ее Место-в-сеансе (ИД, МестоИД, СеансИД, Цена), тут уже можно навести лад и с ценой — от фильма и типа места.
Если крутить дальше, то выходим на новую табличку, назовем ее Место-в-сеансе (ИД, МестоИД, СеансИД, Цена), тут уже можно навести лад и с ценой — от фильма и типа места.
Всегда считал, что основная задача реляционных БД — все же эффективное хранение и выборка данных, а не их валидация.
Проблема: в таблице билетов нет проверки зала сеанса соответствующему залу в таблице мест.
Реляционное решение есть, но с добавлением избыточности и использованием новых ключей (добавленные элементы выделены синим цветом).
Реляционное решение есть, но с добавлением избыточности и использованием новых ключей (добавленные элементы выделены синим цветом).
Статья топовая)
Вы прям великолепно расписали. Обязательно буду кидаться ей в студентов.
Вы прям великолепно расписали. Обязательно буду кидаться ей в студентов.
Э-э-э. Блеск и нищета РМД (СУРБД в частности).
Нужно было сделать БД по продаже билетов, а пришлось строить ещё БД фильмов, БД людей.
И это ещё не глубоко копнули. :-)
Нужно было сделать БД по продаже билетов, а пришлось строить ещё БД фильмов, БД людей.
И это ещё не глубоко копнули. :-)
Спасибо за статью. Отправил своему студентику, которого я пытаюсь курировать. А можно что-то подобное по noSQL? Я бы сам почитал. Сколько раз не пытался разобраться с noSQL (уже 3 «проекта» на них сделал) — там либо всё-равно применяю принципы реляционности, либо бардак и дублирование, от которого у меня бомбит.
Вы сделали отличный материал «на пальцах»! Спасибо.
Тоже преподаю, но школьникам. БД упоминаем «для знакомства». А с вашим материалом теперь можно и задачки на размышление дать.
Тоже преподаю, но школьникам. БД упоминаем «для знакомства». А с вашим материалом теперь можно и задачки на размышление дать.
Статья — хороший пример большого недостатка РМД — многовариантность построения структур БД, что превращает эту задачу в вид искусства.
Не могу согласиться. Это не входит в рамки статьи, но если описать информационные сущности, их ключи и связи, структуру бд можно строить автоматически, потому что вариативности не остаётся. Разработать инфомодель, то есть описать предметную область — вот это ближе к искусству. Но к бд это отношения не имеет.
Спасибо, за статью. Как заново родился!
Пожалуйста, продолжайте этот цикл. Про триггеры там и все такое очень хочется услышать в вашем изложении.
Пожалуйста, продолжайте этот цикл. Про триггеры там и все такое очень хочется услышать в вашем изложении.
Спасибо за статью! Я как раз пишу приложение для миникинотетра)
Sign up to leave a comment.
Как научиться проектировать реляционные базы данных за полчаса