Проектирование базы данных: решение с низкими издержками для управления ежедневными запасами / мощностями? - PullRequest
Новая
       24

Проектирование базы данных: решение с низкими издержками для управления ежедневными запасами / мощностями?

0 голосов
/ 23 марта 2011

Вот сценарий: (MySQL 5.1+, PHP, Apache)

Я планирую приложение SaaS, которое позволит КЛИЕНТАМ посещать МАГАЗИНЫ и заказывать ПОЕЗДКИ. (ВСЕ КОПИИ являются сущностями). Магазины предлагают ПОЕЗДКИ, но у них есть только определенное количество СОТРУДНИКОВ, чтобы направлять ПОЕЗДКИ (запись транзакций). По сути, это проблема управления ежедневной пропускной способностью каждого МАГАЗИНА на основе количества доступных СОТРУДНИКОВ. Какое решение для разработки БД является наилучшим для предоставления этой функциональности таким образом, чтобы снизить издержки?

Вот упрощенное представление объектов базы данных: 

table.clients  
client_id (pk, ai)  

table.shops  
shop_id (pk, ai)  

table.employees  
employee_id (pk, ai)  
shop_id (fk)

table.trips  
trip_id (pk, ai)  
client_id (fk)  
shop_id (fk)
trip_date (date)

СЦЕНАРИЙ 1
Я мог бы выполнить запрос на TRIPS для каждого запроса, когда пользователь хочет просмотреть календарь, например: 

SELECT COUNT(*), 
trips.trip_date, 
trips.shop_id
FROM trips
WHERE shop_id=1
GROUP BY trips.trip_date, trips.shop_id

СЦЕНАРИЙ 2
Создайте сводную таблицу, в которой каждый день будет храниться информация, но эта стратегия кажется кошмарной с накладными расходами. Например, представьте, что есть 1000 магазинов, каждый из которых бронирует 1000 поездок за 365 дней в году и , таблица должна хранить информацию в течение следующих 2 лет (830 дней). Похоже, что 1 / создаст огромную сводную таблицу (830 000 строк), которая будет 2 / запрашиваться 1 000 000+ раз в год (1000 магазинов * 1000 поездок на магазин). Когда КЛИЕНТ забронировал ПОЕЗДКУ, он будет увеличивать номер (или, если поездка отменяется, номер будет уменьшаться), что будет эффективно создавать ежедневный запас / емкость.

Итак, мой вопрос таков: Какой метод является лучшим? Или есть лучший способ сделать это?

Спасибо!

1 Ответ

1 голос
/ 23 марта 2011

Звучит как веселье!

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

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

Я бы порекомендовал что-то вроде вашего "вариант 1 "- использовать запросы для получения данных, хранящихся в нормализованных таблицах, а не вариант 2, который фактически является денормализацией для скорости.

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

В общем, мой совет - работать с нормализованным подходом и измерять производительность;только денормализовать, если вы знаете, что у вас есть проблемы.

...