安排员工 - 使用什么数据结构？

发布于 2024-08-09 07:23:00 字数 583 浏览 4 评论 0原文

问题

我正在尝试为我的软件开发公司中大约 10-20 人编写一个简单的员工调度软件。经过一番考虑，我决定用 Python、Ruby 或 PHP + Postgres/MySQL DB 编写一个 Web 应用程序。在设计数据库模型时，我开始想知道哪种数据结构实际上最适合此类应用程序。

：

显示月视图的应用程序示例与此

 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...”；月表将包含每个员工的此类字符串。

你有什么建议？

原文

Question

I'm trying to write a simple employee Scheduling software for about 10-20 people in my software development company. After some consideration I settled on writing a web app in Python, Ruby or PHP + Postgres/MySQL DB. While designing database models I began to wonder what data structure would actually be the best for that kind of application.

What it will look like

Example of app showing the month view would be similar to this:

 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 ...

where M -> for Morning shift; A -> Afternoon shift etc. (letters can be changed to codes)

What data structure or database design would be the best for this?
I was thinking about storing strings (max of 31 characters -> 1 char , 1 day) similar to -> "MMAANNOOOAAMMNNAAOO..." for each user; Month table would contain such strings for each employee.

What would you suggest?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一生独一 2024-08-16 07:23:00

我会选择三表金博尔星（日期、员工、时间表），因为迟早您会被要求从中创建（要求很高的）报告。谁工作的时间最多？谁周末工作最多？谁周末不工作？为什么我总是安排在周五下午？一周中的哪一天某些员工最有可能不会出现？等等...

表格将是：

TABLE dimDate (
    KeyDate
  , FullDate
  , DayOfWeek
  , DayNumberInWeek
  , IsHoliday
  ,... more here
)

您可以预先填充 dimDate 表 10 年左右 - 可能需要不时调整“IsHoliday”列。

员工表也（相对）很少发生变化。

TABLE dimEmployee (
    KeyEmployee
  , FirstName
  , LastName
  , Age
  , ... more here
)

时间表是您填写工作时间表的地方，我还建议每个班次使用“工作时间”，这样可以轻松在报告中汇总时间，例如：“去年约翰·多伊在假期工作了多少小时？ ”

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

您还可以将 KeyDate、KeyEmployee 和 Shift 组合成一个复合主键，而不是使用代理 KeySchedule，以确保您无法将同一个人安排在同一天的同一班次。如果使用代理键，请在应用程序层检查此项。
查询时，连接表如下：

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

如果使用 MySQL，则可以使用 MyISAM 作为存储引擎并将外键 (FK) 实现为“仅逻辑”——使用应用程序层来处理引用完整性。

希望这有帮助。

I would go with three-table Kimball star (Date, Employee, Schedule), because sooner or later you will be asked to create (demanding) reports out of this. Who worked most nights? Who worked most weekends? Who never works weekends? Why am I always scheduled Friday afternoon? On which day of a week are certain employees most likely not to show up? Etc, etc...

Tables would be:

TABLE dimDate (
    KeyDate
  , FullDate
  , DayOfWeek
  , DayNumberInWeek
  , IsHoliday
  ,... more here
)

You can pre-fill dimDate table for 10 years, or so -- may need to tweak the "IsHoliday" column from time to time.

Employee table also changes (relatively) rarely.

TABLE dimEmployee (
    KeyEmployee
  , FirstName
  , LastName
  , Age
  , ... more here
)

Schedule table is where you would fill-in the work schedule, I have also suggested "HoursOfWork" for each shift, this way it is easy to aggregate hours in reports, like: "How many hours did John Doe work last year on holidays?"

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

Instead of having the surrogate KeySchedule, you could also combine KeyDate, KeyEmployee and Shift into a composite primary key to make sure you can not schedule same person on the same shift the same day. Check this on the application layer if the surrogate key is used.
When querying, join tables like:

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

If using MySQL it is OK to use MyISAM for storage engine and implement your foreign keys (FK) as "logical only" -- use the application layer to take care of referential integrity.

Hope this helps.

回复收藏 0 原文