Планирование сотрудников - какую структуру данных использовать? - PullRequest
12 голосов
/ 28 октября 2009

Вопрос

Я пытаюсь написать простое программное обеспечение для сотрудников, рассчитанное на 10-20 человек, в моей компании по разработке программного обеспечения. После некоторых размышлений я остановился на написании веб-приложения на Python, Ruby или PHP + Postgres / MySQL DB. При разработке моделей баз данных я начал задумываться о том, какая структура данных на самом деле будет лучшей для такого рода приложений.

Как это будет выглядеть

Пример приложения, показывающего просмотр месяца, будет выглядеть примерно так:

 OCTOBER    1 2 3 4 5 6 7 8 9 ...
John Apple  M M A A N N O O O ...
Daisy Pear  O O O M M A A N N ...
Steve Cat   A A N N O O O M M ...
Maria Dog   N N O O O M M A A ...

где М -> для утренней смены; A -> Дневная смена и т. Д. (Буквы можно изменить на коды)

Какая структура данных или дизайн базы данных будет наилучшим для этого? Я думал о хранении строк (не более 31 символа -> 1 символ, 1 день), подобных -> "MMAANNOOOAAMMNNAAOO ..." для каждого пользователя; Таблица месяца будет содержать такие строки для каждого сотрудника.

Что бы вы предложили?

Ответы [ 3 ]

12 голосов
/ 28 октября 2009

Я бы пошел с звездой Кимбалла с тремя столами (Дата, Сотрудник, Расписание), потому что рано или поздно вас попросят создать (требующие) отчеты из этого. Кто работал большинство ночей? Кто работал большинство выходных? Кто никогда не работает по выходным? Почему я всегда намечен на пятницу? В какой день недели некоторые сотрудники, скорее всего, не будут появляться? И т. Д., И т. Д ...

Таблицы будут:

TABLE dimDate (KeyDate, FullDate, DayOfWeek, DayNumberInWeek, IsHoliday,... more here)
Вы можете предварительно заполнить таблицу dimDate на 10 лет или около того - может потребоваться время от времени изменять столбец «IsHoliday».

Таблица сотрудников также изменяется (относительно) редко.
TABLE dimEmployee (KeyEmployee, FirstName, LastName, Age, ... more here)

В таблице расписаний вы должны будете заполнить график работы. Я также предложил «HoursOfWork» для каждой смены, чтобы было легко объединять часы в отчетах, например: «Сколько часов работал Джон Доу в прошлом году в праздники? "

TABLE factSchedule ( <br/>KeySchedule, -- surrogate PK <br/>KeyDate, -- FK to dimDate table <br/>KeyEmployee, -- FK to dimEmployee table <br/>Shift, -- shift number (degenerate dimension) <br/>HoursOfWork, -- number of work hours in that shift <br/>)

Вместо суррогатного KeySchedule вы также можете объединить KeyDate, KeyEmployee и Shift в составной первичный ключ, чтобы убедиться, что вы не можете назначить одного человека на одну и ту же смену в тот же день. Отметьте это на прикладном уровне, если используется суррогатный ключ.
При запросе объединяйте таблицы, например:

SELECT SUM(s.HoursOfWork)<br/> FROM factSchedule AS s <br/>JOIN dimDate AS d ON s.KeyDate = d.KeyDate <br/>JOIN dimEmployee AS e ON s.KeyEmployee = e.KeyEmployee <br/>WHERE <br/>e.FirstName='John' AND e.LastName='Doe' <br/>AND d.Year = 2009 AND d.IsHoliday ='Yes';

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

Надеюсь, это поможет.

empschd_model_01

2 голосов
/ 28 октября 2009

Сначала быстрый ответ:

  • EmployeeID
  • Дата
  • ShiftType

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

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

1 голос
/ 28 октября 2009

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

...