Это хороший способ разработать схему БД для приложения планирования задач? - PullRequest
Новая
       45

Это хороший способ разработать схему БД для приложения планирования задач?

3 голосов
/ 02 ноября 2011

Я делаю список дел в свободное время для обучения и т. Д. Я использую SQL Server Compact 3.5 вместе с Entity Framework для управления данными.Это настольное приложение, предназначенное для использования одним человеком.

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

Я с удовольствием внедрял CRUD для задач, когда думал, что было бы неплохо составить расписание для задач.Начните задание в будущем, повторения ежедневно / еженедельно / ежемесячно / ежегодно / по индивидуальному заказу и т. Д.

Я продолжал пытаться создать свою базу данных с учетом моих ограниченных знаний и пуфа, и в итоге я получил около 14 новых таблиц,Затем я поискал в Интернете и нашел сообщения, указывающие на sysschedules на MSDN .Все выполнено в одной таблице.Я опустил голову от стыда и попытался сделать маленькую попытку улучшить мой дизайн.Я сократил его до 10 таблиц, включая некоторые вещи, которые мне понравились, из таблицы sysschedules.

Теперь это моя (упрощенная) схема (пояснение ниже): Task scheduling database schema

A Задача может иметь SchedulingInfo , связанную с ним.Я принудительно ввел в это OO, поэтому SchedulingInfo - это абстрактный тип, который имеет различные «подклассы».

TimeOfDayToStart_Ticks представляет время начала ... так как я не хочу сохранять его как datetime.

Подклассы:

  • CustomSchedule : Используется, чтобы разрешить выполнение задачи в один прекрасный день, или set дней, в будущем.
  • IntervalSchedule : например.Запускать ежедневно, или каждые 3 дня, или каждые 4 часа и т. Д.
  • Ежемесячный / Годовой график : Установить дней для запуска каждый месяц / год
  • MonthlyRelativeSchedule : Я украл это из вещи sysschedules.Содержит набор дней, которые соответствуют таким вещам, как каждая секунда (частота) суббота (DayType) или последний день недели месяца и т. Д. (См. Вышеупомянутую ссылку, чтобы увидеть полное объяснение).

Мой код будет получать список ScheduleInfo, отсортированный по NextRun.Удалите из очереди ScheduleInfo, создайте новую задачу с соответствующими деталями, пересчитайте NextRun на основе подкласса ScheduleInfo, сохраните ScheduleInfo обратно в БД.

Мне странноколичество столовПовлияет ли это на производительность, если есть тысячи записей?Или это как отвратительный дизайн, полный плохих практик или чего-то подобного?Должен ли я просто использовать подход за одним столом?

1 Ответ

2 голосов
/ 04 ноября 2011

Да, я думаю, что ваш настольный поток окажет негативное влияние на производительность.Если YearlySchedule и другие вещи являются производными от базовой сущности SchedulingInformation и у вас есть отдельные таблицы для базовых и производных свойств, вы вынуждены использовать Таблица-на-тип отображение наследования, которое известнобудь медленным(По крайней мере, до текущей версии 4.1 EF. Объявлено, что сгенерированный SQL для запросов с отображением TPT будет улучшен в следующей версии EF.)

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

Я бы отбросил эти четыре класса, а также пятый - IntervalSchedule - и добавил бы егоодиночное свойство Interval_Ticks к таблице SchedulingInformation.

Все четыре таблицы ...Specifiers могут ссылаться с помощью своих внешних ключей на таблицу SchedulingInformation.

Таким образом, это приведет кв:

  • Пять таблиц: SchedulingInformation и 4 x *Specifiers
  • Одна абстрактная базовая сущность: SchedulingInformation
  • Пять производных сущностей: *Schedule
  • Четыре сущности: *Specifier

Каждая из *Schedule сущностей (кроме IntervalSchedule) имеет коллекцию соответствующих *Specifier сущностей (один-ко-многим)отношения).И вы сопоставляете пять *Schedule сущностей с одной и той же таблицей SchedulingInformation через отображение наследования Table-Per-Hierarchy.

Это будет мой основной план, чтобы попытаться и протестировать.

...