【发布时间】：2011-04-11 21:18:45
【问题描述】：
我正在使用 CakePHP 框架开发一个应用程序，目前正在设计数据库。我想确保我正确设计了对象及其关联，以便应用程序运行良好、组织正确、可扩展且可扩展。我将首先详细描述应用程序，并提出一个对象关系模型。我需要一些关于最佳实践和 CakePHP 约定的指导。请仔细阅读说明，然后在下面解决我的问题。
如果您需要任何澄清，请发表评论。
申请背景和要求
该应用程序将用作各种专门的 CRM。客户将使用它来跟踪和管理客户、联系人、工作、库存、供应商和机会。客户端当前有一个无组织的大型数据库和损坏的应用程序代码。他们需要使用 CakePHP ORM 和在数据结构之上构建的新应用程序从头开始重建数据库。该数据库将在 MySQL 中构建。该应用程序将需要支持具有访问控制列表的多种用户类型。它需要被设计为有效扩展，并且以后需要在对象模型之上构建新的应用程序。
提议的对象（子项目符号从上面的对象继承）
- 公司 - 与客户有业务往来的任何公司
- 客户 - 客户的客户
- 承包商 - 与客户签约从事工作的公司
- 供应商 - 向客户提供零件或服务的公司
- 制造商 - 制造零件的公司
- Account - 封装客户与其客户之间关系的对象
- 工作 - 公司提供的工作单元
- 任务 - 与特定工作相关的收费服务
- 部件 - 作为作业或任务的一部分由客户安装的项目
- InventoryItem - 库存中的零件
- Person - 一个人的记录
- 员工 - 与客户打交道的公司之一的员工
- 技术员 - 客户雇用的服务技术员
- 联系人 - 与客户打交道的特定公司的联系人
- 管理员 - 网站管理员
- 机会 - 任何给定帐户的潜在工作机会
提议的关系
(HO = hasOne, HM = hasMany, BT = belongsTo, HABTM = hasAndBelongsToMany)
- 公司
- HM：联系人、技术员、员工
- HABTM：管理员
- 制造商从公司继承
- 供应商从公司继承
- 承包商从公司继承
- 客户从公司继承
- HM：帐户
- 工作
- BT：帐号
- HM：任务
- HABTM：零件、承包商、技术员
- 任务
- BT：工作
- HABTM：零件、承包商、技术员
- 部分
- HABTM：供应商
- 库存物品
- 何：部分
- 员工从个人继承
- BT：公司
- 技术员从人继承
- BT：公司
- 联系人从 Person 继承
- BT：公司
- Administrator 从 Person 继承
- 机会
- BT：帐号
我已尽力在 UML 图上说明这一点，尽管我不确定我是否得到了正确的符号约定： http://twitpic.com/2o5r0a
我的问题和疑虑
- 如果有的话，您会对此架构进行哪些更改？为什么？
- 在 CakePHP 中处理对象继承的最佳方式是什么？
- 引导客户了解此架构并解释其如何满足项目要求的最佳方式是什么？
- 这个提议的设计是否会带来任何潜在的可扩展性问题？
- 您认为这种设计会在开发应用程序代码时造成任何困难吗？
- CakePHP 兽医对此有何智慧之言？
【问题讨论】：
-
我认为这不适合这个论坛。 -1
-
来自常见问题解答：“避免提出......需要扩展讨论的问题。”这个问题不是一个特定的问题，您是在要求某人为您工作或您的直线经理为您工作。
-
不，我认为发布规范有点厚脸皮，希望有人阅读并理解它，然后花一些时间来评估和评论它。这里的大多数人都在从事自己的项目，并由其他人支付费用。时间就是金钱。这里的每个人都准备好花一些时间帮助他人，作为回报，他们自己的问题也经常得到解决，但对于这个问题，你要求很多。而且我已经花了足够多的时间了。
-
我必须同意@Leo。这是一个非常广泛的问题，大多数人会在职业生涯中收取费用。很明显，您已经为此投入了一些时间，发现此设计中的缺陷将花费更多时间，而且如果不详细了解项目要求，可能毫无意义。我赞赏你提出这个问题的努力，但我怀疑你会得到任何答案。您应该将其精简到您关心的具体点，这可能是一个可以回答的问题。
-
@adam - 耗时的问题并不总是很糟糕，但它们必须很有趣：stackoverflow.com/questions/3684484/…。同意 @deceze 的观点，这通常是您向顾问支付的专业知识。
标签： database-design orm cakephp scalability entity-relationship