Как ограничить число отношений к записи?

Question

[Phoen1xx]

Здравствуйте. Мне требуется создать между таблицами отношение один к N. Я пишу тестовый сайт, на котором можно забронировать столик в ресторане. У меня возникла проблема при работе с таблицами:
restaurant
reserved
В restaurant хранится описание ресторана, а также число столиков. Когда пользователь бронирует столик, создается запись в reserved, со ссылкой на id ресторана, но получается что можно создать любое кол-во броней.

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

Comments

[Daria Motorina]

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

Answer 1

[DevMan]

Читаем о транзакциях.

Comments

[Phoen1xx]

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

[DevMan]

Phoen1xx, транзакции позволяют откатить все изменения, если что-то пошло не так.

[Phoen1xx]

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

[DevMan]

Phoen1xx, шта?

[Phoen1xx]

DevMan, запросы это же просто способ изменения или получения данных из бд. Для хранения отношения между собой данных мы используем ключи, внешние, уникальные и т.д. чтобы бд самостоятельно контролировала правильность хранения данных. Если я вынесу это ограничение на кол-во брони в зарос, получается бд не будет контролировать правильность данных и может быть ситуация когда кто-то, поддерживая например этот проект, не учтет это и мы получим мусор в бд. Разве использование транзакций таким образом не портит логику проекта?

[DevMan]

Phoen1xx, вы спросили "как учесть бронь при конкурентном доступе", я вам ответил.
остальное - непонятные мне фантазии.

Answer 2

[Phoen1xx]

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

Answer 3

[bioroot]

На самом деле очень интересный вопрос. Логику, которую вам предлагают выше, всё-равно придётся использовать. Т.е. начинаем транзакцию, пробуем воткнуть данные, если что-то пошло не так - откатываем транзакцию. Но, насколько я вас понял, в первую очередь вам не нравится, что ограничения на количество мест придётся выносить в код, и откатывать транзакцию тоже из кода. Это нормальная практика, но если очень хочется вынести ограничения в базу - посмотрите в сторону CONSTRAINT. Правда есть эта штука только в последней версии MySQL (в PostgreSQL есть давно). С помощью этих проверок вы можете, например, создать колонку с количеством свободных мест в ресторане и потребовать, чтобы оно было не отрицательно. Тогда на уровне кода вам нужно будет только не забыть скрутить на единицу счётчик свободных мест. Если ограничение будет нарушено, то база плюнет ошибкой и транзакция откатится.

Answer 4

[Константин Цветков]

UNIQUE Constraint.

Answer 5

[Rsa97]

Как именно пользователь бронирует столик? Скорее всего на определённое время, то есть, например, с 15 до 18. При этом, наверняка, есть некоторый шаг бронирования (например, 1 час). Соответственно, появляются слоты 15, 16, 17 часов.
Значит в таблицу записывается id столика и временной слот бронирования. Создаётся уникальный ключ (id_столика, слот). Запись всех слотов делается в рамках одной транзакции, тогда никто не сможет вклиниться в процедуру сохранения бронирования.

Comments

[Phoen1xx]

Да, действительно мне приходится также учитывать время, я опустил эту информацию в вопросе т.к. с этим проблем нету. Выше уже предлагали использовать транзакции, и у меня возникает вопрос, разве это не испортит логику хранения данных, мы получается выносим условие хранения данных в запрос, и в случаи утери этого запроса бд не будет знать как хранить правильно данные. Разве это хорошее решение? Просто это похоже на ситуацию, как если бы мы убрали у какого нибудь поля уникальность, и добавили для контроля транзакции, это получится потенциально проблемное место.

[Rsa97]

Phoen1xx, Ограничение дублирования на уровне базы делается уникальным ключом. Транзакция нужна, чтобы исключить ситуации, когда между запросом на поиск столика и запросом на его бронирование вклинивается запрос из другого потока:
Поток A: ищет свободные столики
Поток Б: ищет свободные столики, получает те же самые, что и поток А.
Поток А: резервирует столик
Поток Б: пытается зарезервировать тот же столик.