首次数据库设计:我是否过度设计?
背景
我是 CS 一年级的学生,我为我父亲的小企业做兼职。我在现实世界的应用程序开发方面没有任何经验。我用 Python 写过脚本,用 C
写过一些课程,但没有这样的东西。
我父亲有一家小型培训公司,目前所有课程都通过外部网络应用程序安排、记录和跟进。有一个导出/“报告”功能,但它非常通用,我们需要特定的报告。我们无权访问实际数据库来运行查询。我被要求建立一个自定义报告系统。
我的想法是创建通用的 CSV 导出并将它们导入(可能使用 Python)到每晚托管在办公室的 MySQL
数据库中,从那里我可以运行所需的特定查询。我没有数据库方面的经验,但了解非常基础的知识。我已经阅读了一些关于数据库创建和普通表单的内容。
我们可能很快就会开始拥有国际客户,所以我希望数据库在发生这种情况时不会爆炸。我们目前还有几家大公司作为客户,拥有不同的部门(例如 ACME 母公司、ACME
医疗保健部门、ACME 身体护理部门)
我想出的架构如下:
- 从客户的角度来看:
- 客户是主表
- 客户与他们工作的部门相关联
- 部门可以分散在一个国家/地区:伦敦的人力资源部,斯旺西的营销部等。
- 部门与公司的部门相关联
- 部门与母公司相关联
- 从类的角度来看:
- 会话是主表
- 每节课都有一位老师
- 每个会话都有一个 statusid。例如 0 - 已完成,1 - 已取消
- 会话被分组为任意大小的“包”
- 每个包都分配给一个客户
我在一张纸上“设计”(更像是潦草)模式,试图将其规范化为第三种形式。然后我将它插入 MySQL Workbench,它对我来说很漂亮:(
单击此处查看全尺寸图形)
(来源:maian.org)
我将运行的示例查询
- 哪些仍有信用的客户处于非活动状态(未来没有安排课程的客户)
- 每个客户/部门/部门的出勤率是多少(以每个会话中的状态 ID 衡量)
- 一个老师一个月有多少节课
- 标记出勤率低的客户
- 人力资源部门的自定义报告,包含其部门人员的出勤率
问题)
- 这是过度设计还是我走对了路?
- 大多数查询需要连接多个表会导致性能大幅下降吗?
- 我已经向客户添加了一个“lastsession”列,因为它可能是一个常见的查询。这是一个好主意还是我应该严格规范数据库?
谢谢你的时间
-
您的问题的更多答案:
1)对于第一次解决此类问题的人来说,您几乎是目标。我认为迄今为止其他人关于这个问题的指示几乎涵盖了它。做得好!
2 & 3)
您将受到的性能影响在很大程度上取决于为您的特定查询/过程拥有和优化正确的索引,更重要的是记录量。除非您在主表中谈论超过一百万条记录,否则您似乎正朝着拥有足够主流的设计的方向前进,在合理的硬件上性能不会成为问题。就是说,这与您的问题 3
相关,从一开始您可能不应该过分担心性能或对这里的规范化正统观念过于敏感。这是您正在构建的报告服务器,而不是基于事务的应用程序后端,它在性能或规范化的重要性方面会有很大不同。支持实时注册和调度应用程序的数据库必须注意需要几秒钟才能返回数据的查询。报表服务器功能不仅对复杂冗长的查询有更大的容忍度,而且提高性能的策略也大不相同。例如,在基于事务的应用程序环境中,您的性能改进选项可能包括将存储过程和表结构重构到第 n
级,或者为少量常用数据开发缓存策略。在报告环境中,您当然可以这样做,但您可以通过引入快照机制对性能产生更大的影响,其中计划进程运行并存储预配置的报告,并且您的用户访问快照数据而不会对您的数据库层造成压力每个请求的基础。所有这些都是冗长的咆哮,以说明鉴于您正在创建的数据库的角色,您采用的设计原则和技巧可能会有所不同。我希望这会有所帮助。