При оптимизации моей таблицы «событий», должен ли я больше беспокоиться о количестве полей или количестве взаимосвязанных таблиц?

Question

Этот вопрос является ответом на предыдущий вопрос, который я задавал о том, как лучше всего моделировать различные временные величины и временные рамки: Как хранить в базе данных даты и сроки возникновения событий для быстрых и элегантных запросов?

Учитывая таблицу событий , я бы хотел самый простой способ моделировать и запрашивать события, которые имеют такие события:

• Единовременно : 12 декабря 2014 года в рокхаусе состоится концерт группы XY Rock
• Ежегодно : Доброволец на суповой кухне утром в День Благодарения
• Ежемесячно : Каждую первую субботу бесплатная ночь в МоМА
• Еженедельно : обычные рабочие часы

Я бродил по схеме в этой форме:

• Имя
• Описание
• start_datetime
• end_datetime
• period_type (строка, например, «Еженедельно», «Ежемесячно»)
• пн (логическое)
• 1042 * Вт *
• ср
• ЧГ
• 1048 * ПТ * * * Сели тысяча сорок-девять
• солнце (все логические значения)
• расписание (текст)
• частота_ описание (текст)

Обычный сценарий использования, который я предвижу, заключается в том, что в определенный вторник ... скажем, 5/4/2016 я хочу найти все, что происходит в этот вторник ... включая все предприятия, которые открыты по обычным вторникам, все, что происходит ежемесячно во вторник, и все, что происходит в эту конкретную дату.

Таким образом, запрос псевдокода будет выглядеть примерно так:

SELECT * from events WHERE `tues`=TRUE || DATE(start_datetime) = '2016-04-05'

На уровне приложения / контроллера я мог бы применить необходимую логику к исключить все "ежемесячные" события вторника, которые не происходят в первый вторник, используя ключ / хранилище в Frequency_description (для обсуждения я собираюсь проигнорировать «ежегодный» крайний случай, когда что-то случается каждый четвертый четверг ноября или что-то подобное). Было бы неплохо сделать это исключение в запросе, но я не уверен, как спроектировать таблицу, чтобы позволить это, и при этом сохранить простой SELECT.

Я также предсказываю, что нет необходимости делать запрос, в котором я нахожу, что все предприятия открыты во вторник в 9:00 ... Таким образом, отдельные поля дня могут быть просто логическими с эффективным использованием пространства с графиком * Поле 1073 * является датой хранения моей ненормализованной конкретной информации. Приложение будет иметь логику для анализа и форматирования для отображения.

Это перебор? Допустим, 70% моих событий будут одноразовыми, что устраняет необходимость в понедельник, вторник, субботу и т. Д., А также в расписании и в тексте-ключах-хранилищах Frequency_description ...

Должны ли я вместо этого иметь две таблицы? Один для событий, а другой для какого-то события_отношения, в котором соединяются day_fields и key-store-textfields?

Это похоже на более эффективное использование пробела ... с другой стороны, мой запрос должен быть SELECT и JOIN ... который может быть медленнее.

Когда речь идет о количестве записей от 10 до 100 Кб, и при простом хостинге в EC2 ... я должен больше заботиться об эффективном использовании пространства в моей базе данных (не только о чистом пространстве хранения данных, но и всех связанных с этим издержках с текстом поля и многочисленные столбцы) ... или мне нужно больше заботиться о простых операторах SELECT?

Answer 1

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

Хотя это не очень хорошо для местаиспользование ... вы можете сделать несколько ярлыков, которые говорят, что события, которые происходят "каждый вторник с настоящего момента и до конца всех времен", время окончания может на самом деле по умолчанию сказать 200 лет в будущем, это означает, что вы только заполняете10k записей (52 * 200) в этом крайнем случае.

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

Итак, у вас есть что-то вроде этого:

Events table = Your current schema
Event occurrence table = {event_id, start_datetime, end_datetime}

Предположим, у вас есть 1000 еженедельных повторяющихся событий (и мы предполагаем, что выперейдите на 200 лет, если не endDate), то есть, скажем, 10M записей, затем вы индексируете поле start_datetime поля Event occurrence table, и ваш запрос будет оченьИ даже с гораздо большим количеством записей, чем эта.Сравните затраты на это (снижение производительности при записи и использование большего пространства) с необходимостью найти каждое событие, которое today is between startdate and enddate, а затем рассчитать, действительно ли событие происходит сегодня.

В конце концов, все сводится к нулю.на:

• 'сколько места вам стоит?'
• 'как часто вы собираетесь обновлять записи (и хотите ли вы обновить все записи, включая исторические записи для события)? '
• и' как часто вы хотите запускать выборку на определенную дату?(вероятно, очень часто)