Оптимальная стратегия структуры схемы базы данных для данной ситуации

Question

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

(Примечание: это абстрактное описание того, что я делаю, само приложение, которое я создаю, очень похоже по структуре, но не состоит из реальных компонентов, которые я назвал ниже.)

Я создаю приложение, которое будет состоять из: 1. Менеджеры номеров 2. Комнаты 3. Гости

Каждый менеджер комнаты может выбрать любое количество комнат для управления, и гости могут зарегистрироваться, чтобы находиться в комнатах, которыми управляет менеджер комнаты. Гости могут также выбрать других гостей, чтобы быть частью их «окружения» в комнате. Я набросал схему таблиц, которые я собираюсь использовать для реализации базы данных этой системы:

Еще одна важная вещь, которую стоит отметить, это то, что этот процесс будет повторяться раз в неделю. Менеджеры выберут комнаты для управления, и гости подпишутся, чтобы быть в этих комнатах, и приведут окружение других гостей. Поэтому со временем размеры таблиц manager_rooms, guest_reservations и guest_entourage будут увеличиваться быстрее всего. Я хочу дать менеджерам возможность видеть всех гостей, которые зарегистрировались, чтобы быть в их комнатах вместе с окружением этого гостя, так что это означает, что мне придется запрашивать таблицы guest_reservations и guest_entourage (предположительно, с помощью операции соединения).

Мой вопрос: является ли эта стратегия в целом хорошей и будет ли она вызывать проблемы по мере ее масштабирования и роста? Я использую MySQL с таблицами InnoDB и ограничениями внешнего ключа + индексы btree, где это было бы уместно. Есть указатели? Подсказки? меры предосторожности? Спасибо!

EDIT2: Я буду делать так, чтобы для таблицы 'manager_rooms' в качестве ключа использовалась уникальная комбинация менеджеров, номеров и дат. date с использованием поля MySQL DATE.

Answer 1

«хорошо» действительно сложно оценить - единственные критерии, которые вы упоминаете, - это масштабируемость.

В целом, я бы сказал, что ваше предложение должно работать достаточно хорошо - единственное уточнение, которое я бы предложил (аналогично PPrice), заключается в том, что если у вас действительно есть понятие «период» - например, неделя- вы можете смоделировать это как отдельную таблицу в вашей базе данных и связать резервирования с этим периодом.

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

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

Я бы также посмотрел на другие критерии оценки - ремонтопригодность часто упускается из виду.

Answer 2

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