Нужна помощь в разработке логики БД

Question

Это мой мини-проект - система бронирования авиабилетов - давайте назовем эту авиакомпанию FlyMi: у меня есть база данных (не решено, какой мой друг хочет пойти с MongoDB).

В любом случае, это мое требование: у меня есть таблица с подробной информацией о рейсе - номер рейса, расписание и т. Д. Я собираюсь использовать эту таблицу для выполнения различных операций - бронирования, отмены, изменения

Вот где я застрял: для настольного приложения и веб-приложения - я предлагаю вариант выбора мест. Это означает, что я должен следить за тем, какие места забронированы, а какие нет. И предположим, у меня есть интерфейс, который показывает места как
Красный - забронировано
Зеленый - не забронировано.

И все это - для каждого полета. Мой вопрос: как вы думаете, что будет наиболее эффективным способом отслеживания бронирования мест для каждого рейса в этой авиакомпании?

Текущая идея: сохранить таблицу с именем пассажира - со всеми данными, такими как имя, адрес и т. Д., Которые отслеживают всех пассажиров, и поддерживать идентификатор пассажира таким образом, чтобы первые 4 символа были идентификатором рейса, а последние 2 символа - номерами сидений, которые у них есть. выбранный, со случайным числом между (я говорю случайный, потому что я думаю, что это несущественно). Таким образом, для любого рейса, если мне нужно будет узнать количество незабронированных мест, мне нужно будет просканировать каждого пассажира, который забронировал и который забронировал этот рейс. Я думаю, что это действительно неэффективно. Предоставьте мне наиболее эффективную логику для этого.

Answer 1

Не используйте "умные ключи".

Это плохая идея, называемая "умные ключи" или "кодирование информации в ключах".

Смотрите этот ответ, который содержит этот отрывок:

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

Умные ключи также имеют тенденцию перерастать свои исходные ограничения кодирования

(Обратите внимание, что места на сиденьях обычно идентифицируются интеллектуальными клавишами в том смысле, что они представляют собой номер строки и число в ряду. Но они также обычно визуально физически навсегда прикреплены к этой формации. И представьте, были ли они помечены и переставлены.)

Узнайте больше о дизайне базы данных.

Просто опишите свой бизнес в самых простых терминах. Так работают базы данных и СУБД реляционных моделей.

Найдите достаточно шаблонов предложений "Заполните [именованные]", чтобы описать ваши бизнес-ситуации:

"customer [cid] has name [firstname] [lastname]
    AND customer [cid] has a phone number [phonenumber] of type [type] ..."
"customer [cid] can use credit card #[card_no]"
"seat [seatid] is at row [row] and column [column]"
"seat [seatid] is booked"
"seat [seatid] is temporarily committed to an unfinished booking"
...

Для каждого такого параметризованного шаблона предложения (он же предикат) есть базовая таблица, где имена пробелов / параметров являются именами столбцов. В каждой строке таблицы указывается утверждение (предложение), полученное при заполнении пробелов в значениях его столбцов; В каждой строке, не входящей в таблицу, НЕ указывается оператор заполнения пробелов в значениях столбцов.

Затем для каждой таблицы найдите каждую функциональную зависимость (FD), которая имеет место. (Когда предикат может быть выражен в форме "... AND column = F (column1,...)", тогда мы говорим, что набор столбцов { column1,...} функционально определяет столбец столбца и что FD set → column содержит.) Затем определите каждый ключ-кандидат (CK). (Суперключ - это набор столбцов, который функционально определяет каждый столбец. Т.е. он уникален, т. Е. Где каждая подстрока значений для этих столбцов появляется только в одной строке таблицы. CK - это суперключ, который не содержит меньший суперключ.) Затем найдите все зависимости соединения (JD). (Некоторые предикаты говорят "... И..." для некоторого числа AND и "...". Существует JD, когда таблица для каждого предиката "..." будет выглядеть так, как если бы вы взяли только его столбцы из исходной таблицы.) Обратите внимание, что каждый FD поставляется со связанным (двоичным) JD.

Затем нормализуйте свои таблицы до пятой нормальной формы (5NF). Это означает декомпозицию (т. Е. Замену таблицы, в которой JD "... AND ..." выполняется на таблицы, предикаты которых являются "..."), пока каждый JD, который содержит, подразумевается CK (то есть должен выполняться, когда JD из FD из CK удерживают.) (Из соображений производительности можно также денормализовать, комбинируя с базовыми таблицами, которые не находятся в 5NF.)

Смотрите этот ответ и этот.

Затем мы запрашиваем, описывая строки, которые мы хотим. Мы делаем это, соединяя предикаты базовой таблицы с логическими операторами (то есть AND, OR, NOT, FOR SOME, FOR ALL и т. Д.) И вызовами функций, чтобы дать предикаты для нужных нам таблиц, и / или соединяя имена базовых таблиц операторами отношений (т. е. JOIN, UNION, MINUS/EXCEPT, PROJECT/SELECT, RENAME/AS), чтобы дать значения таблиц, которые мы хотим, и / или обе (например, RESTRICT/WHERE).

СОЕДИНЕНИЕ двух таблиц содержит строки, которые делают истинное утверждение, то есть имеют в качестве предиката AND своих предикатов; и СОЮЗ ИЛИ, МИНУС / ЗА ИСКЛЮЧЕНИЕМ И НЕ; и что столбцы PROJECT / SELECT таблицы помещают FOR SOME all-other-columns перед ее предикатом; и RESTRICT / WHERE ставит условие AND после его предиката; и RENAME / AS столбца переименовывает этот параметр в его предикат. Таким образом, выражение таблицы соответствует предикату: значение таблицы (базовая таблица или результат запроса) содержит строки, которые делают истинный оператор из своего предиката (базовая таблица или выражение запроса).

Смотрите этот ответ.

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

Смотрите этот ответ.