Структура и эффективность проекта

Question

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

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

Я думал о создании трех таблиц:

• событие [информация о расписании дней, цене и максимальном количестве участников]
• клиент [информация о клиенте и ссылка на идентификатор мероприятия / идентификатор бронирования]
• бронирования [содержит количество участников за каждый день (со ссылкой на событие и клиентов), а также возможные исключения, такие как изменение цены, лимит разных участников и т. Д.]

Надеюсь, что неясно, что я здесь пытаюсь ... Я пытаюсь сосредоточиться только на скорости в календаре, который проверяет таблицу заказов и выводит, забронирован ли уже весь день [таблица заказов с таблицей событий] или нет, и какова текущая цена для него. Административная панель тоже должна быть достаточно быстрой, чтобы было легко перечислить все заказы или получить доступ к определенному дню.

Теперь перейдем к реальным вещам ... Может быть, я использую неправильный подход для разделения данных таким образом, но, очевидно, существуют некоторые недостатки, когда речь идет о массовых изменениях, поскольку мне пришлось вставить много исключений в таблицу заказов или создать новую запись для события и изменить старую один, который немного грязный в моих глазах (особенно когда вы получили больше, чем несколько исключений). В любом случае я получу кучу записей, хотя на самом деле я хотел поддерживать систему немного более автоматизированной, например, иметь несколько расписаний и позволить PHP делать все остальное (думаю, это быстрее, чем запрашивать MySQL).

Так что вы думаете? Я не могу придумать никакого другого разделения данных. Вероятно, проще всего было бы создать одну запись БД для каждого дня и каждого события, но я думаю, моя мама могла сказать, что это плохо и медленно.

Answer 1

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

Сказав это, ваш вопрос не совсем ясен - но я бы рискнул следующими идеями.

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

Во-вторых, вы, кажется, беспокоитесь о количестве событий, которые вы создаете; Я не думаю, что вам нужно. Даже если каждый день происходит 10 событий и вы планируете заблаговременно на 10 лет, вы все равно имеете дело только с несколькими десятками тысяч записей - это далеко не за пределами MySQL. Кроме того, поиск в базе данных будет намного проще поддерживать (и, возможно, быстрее), чем сложная логика в PHP, связанная с поиском исключений.

Итак, я бы подумал о создании следующих таблиц:

EventType

ID Description     Duration    Price
------------------------------------
1   1 day event          1       10
2   2 day event          2       15

EventInstance

ID  EventTypeID  StartDate   EndDate      Duration    Price
1   1            1 Jan 2012  2 Jan 2012          1       10 //Regular event
2   1            1 Feb 2012  2 Feb 2012          1       20 //Special price exception
3   1            1 Mar 2012  3 Mar 2012          2       25 //Special duration and price exception

Вы можете заполнить таблицу «EventInstance», просматривая любую логику даты, а затем настраивая записи для «исключений»

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

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

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