概括工单
Generalizing work orders
你好 Whosebugians，
我正在为工单设计 tables。
问题：
- 有不同的工单模型（以后称为WOM）
- WOM 共享一些属性（编号、日期、描述等）
- WOM 包含以下详细信息：
- 工作完成的扇区。
- 一些 WOM 使用储罐而不是扇区（产品在储罐中准备）。
- 适用于哪个行业的产品及其数量（加上或不加一些关于产品的信息）。
- 在 WO 工作的人力资源。
- 工单上使用的材料
- ...等等
需要什么
- 为工单设计 tables 和 c 的详细信息。
- 他们想知道资源是如何花费的。
- 设计查询以检索所有形状的信息。
约束
- 面向最终用户的简单介绍。
- 概括工单模型。
做了什么
将所有工单及其详细信息设计为以工单编号为母节点的层次结构。
WorkOrderTable (ID, ParentID, Type, Value)
工单示例
ID ParentID Type Value
38 0 Num 327
39 38 Sector 21
40 38 Sector 22
43 40 Product NS
44 40 Product MS
50 40 Temp RAS
48 44 Quantity 60
47 43 Quantity 25
41 39 Product ARF
42 39 Product BRF
49 39 Temp RAS
51 39 Cible Acarien A.
46 42 Quantity 30
52 42 Cible Acarien B.
45 41 Quantity 20
问题
我正在做的事情 good/efficient 易于维护还是有其他想法？
更新一：更多细节
- 大约 50 个活跃的产品没有变化[产品随时间变化，需要跟踪版本]
- 扇区约40个（固定土地面积）
- 人正常心率table
- 典型的口碑有多大：
- 大约 15 个属性（其中 3 个很重要，所有 WOM 都共享，其他的则少一些）
- 大约 5 个或更多详细信息共享：产品、行业、人员和其他描述信息，例如产品数量。
- 口碑目前是固定的，但我担心它们在未来会发生变化（或新的口碑兴起）
- 版本控制现在不是必需的，但添加它是一个加号。
- 我计划为参与者（行业、产品...）使用不同的 table
- 元数据/数据冲突是这个设计困境的症结所在。
- 认为任何 WOM 都由 3 个部分定义：
- 工单一般信息（编号、日期...）
- 完成工作的部门[其他 WOM 使用罐式存储]。
- 完成工作的资源产品、人员、机器...
State of the design
- Specific tables for participants sectors,people,machines...
Meta-data table (ID, meta-data, lvl). Example :
- Sector, 1 (directly to WO)
- Tank Storage, 1
- Product, 2 (can be part of sector job not directly to WO) sd
Work Order table (ID, parentID, metadataID, valueID) the value ID is taken from the participants table
关于 XML 我对如何存储和操作它们一无所知。
我想如果你在寻找设计建议，你应该去元堆栈组，即 code review exchange
话虽如此，您征求有关设计的建议，但只提供抽象信息。一个系统的规模，量CRUD expected, and several other factors need to be considered in design. With out getting the details and targets its really hard to answer your question. There are trade offs with different approaches. It may even be advisable to use a nosql solution。
话虽这么说，我还是建议不要构建自己的 ERP 系统，而是从供应商那里购买一个特定于行业的系统，然后将您的定制应用于它。
编写自己的系统非常昂贵，保持更新、增加安全性和许多其他功能使得从软件供应商处购买是一个值得的商业决策。
如果您只是想通过编写本文获得更多经验，我建议您浏览 github 和前面提到的堆栈交换。
在不知道任何数字和进一步了解您的需求的情况下，不可能提供好的建议。这是我想到的一些问题
- 有多少用户？
- 有多少 products/locations/sectors/people...？
- 这是在更改数据吗？
- 有多少口碑？
- 如何大是一个典型的口碑？
- 它是一个普通的树层次结构吗
- 如果没有：是否有替代路线、圈子、岛屿？
- 这些 WOM 是修复了还是改变了？
- 如果更改：您需要版本控制吗？
看起来像是在尝试重新发明一个专业的 ERP 系统。正如 Bostwick 已经告诉您的那样，您应该考虑使用现有的...
只是一些一般提示：
- 不要将 WOM 存储用于（元）数据（仅 ID/外键）
- 尝试在工作数据和元数据之间划清界限
- 为每个 参与者（行业、产品...）使用专用 table
- WOM 最好放在 XML
中
- 了解 (Finite) State Machines
- 了解 state pattern
- 了解 Business-Process-Modelling 和工作流程
你好 Whosebugians，
我正在为工单设计 tables。
问题：
- 有不同的工单模型（以后称为WOM）
- WOM 共享一些属性（编号、日期、描述等）
- WOM 包含以下详细信息：
- 工作完成的扇区。
- 一些 WOM 使用储罐而不是扇区（产品在储罐中准备）。
- 适用于哪个行业的产品及其数量（加上或不加一些关于产品的信息）。
- 在 WO 工作的人力资源。
- 工单上使用的材料
- ...等等
需要什么
- 为工单设计 tables 和 c 的详细信息。
- 他们想知道资源是如何花费的。
- 设计查询以检索所有形状的信息。
约束
- 面向最终用户的简单介绍。
- 概括工单模型。
做了什么
将所有工单及其详细信息设计为以工单编号为母节点的层次结构。
WorkOrderTable (ID, ParentID, Type, Value)
工单示例
ID ParentID Type Value
38 0 Num 327
39 38 Sector 21
40 38 Sector 22
43 40 Product NS
44 40 Product MS
50 40 Temp RAS
48 44 Quantity 60
47 43 Quantity 25
41 39 Product ARF
42 39 Product BRF
49 39 Temp RAS
51 39 Cible Acarien A.
46 42 Quantity 30
52 42 Cible Acarien B.
45 41 Quantity 20
问题
我正在做的事情 good/efficient 易于维护还是有其他想法？
更新一：更多细节
- 大约 50 个活跃的产品没有变化[产品随时间变化，需要跟踪版本]
- 扇区约40个（固定土地面积）
- 人正常心率table
- 典型的口碑有多大：
- 大约 15 个属性（其中 3 个很重要，所有 WOM 都共享，其他的则少一些）
- 大约 5 个或更多详细信息共享：产品、行业、人员和其他描述信息，例如产品数量。
- 口碑目前是固定的，但我担心它们在未来会发生变化（或新的口碑兴起）
- 版本控制现在不是必需的，但添加它是一个加号。
- 我计划为参与者（行业、产品...）使用不同的 table
- 元数据/数据冲突是这个设计困境的症结所在。
- 认为任何 WOM 都由 3 个部分定义：
- 工单一般信息（编号、日期...）
- 完成工作的部门[其他 WOM 使用罐式存储]。
- 完成工作的资源产品、人员、机器...
State of the design
- Specific tables for participants sectors,people,machines...
Meta-data table (ID, meta-data, lvl). Example :
- Sector, 1 (directly to WO)
- Tank Storage, 1
- Product, 2 (can be part of sector job not directly to WO) sd
Work Order table (ID, parentID, metadataID, valueID) the value ID is taken from the participants table
关于 XML 我对如何存储和操作它们一无所知。
我想如果你在寻找设计建议，你应该去元堆栈组，即 code review exchange
话虽如此，您征求有关设计的建议，但只提供抽象信息。一个系统的规模，量CRUD expected, and several other factors need to be considered in design. With out getting the details and targets its really hard to answer your question. There are trade offs with different approaches. It may even be advisable to use a nosql solution。
话虽这么说，我还是建议不要构建自己的 ERP 系统，而是从供应商那里购买一个特定于行业的系统，然后将您的定制应用于它。
编写自己的系统非常昂贵，保持更新、增加安全性和许多其他功能使得从软件供应商处购买是一个值得的商业决策。
如果您只是想通过编写本文获得更多经验，我建议您浏览 github 和前面提到的堆栈交换。
在不知道任何数字和进一步了解您的需求的情况下，不可能提供好的建议。这是我想到的一些问题
- 有多少用户？
- 有多少 products/locations/sectors/people...？
- 这是在更改数据吗？
- 有多少口碑？
- 如何大是一个典型的口碑？
- 它是一个普通的树层次结构吗
- 如果没有：是否有替代路线、圈子、岛屿？
- 这些 WOM 是修复了还是改变了？
- 如果更改：您需要版本控制吗？
看起来像是在尝试重新发明一个专业的 ERP 系统。正如 Bostwick 已经告诉您的那样，您应该考虑使用现有的...
只是一些一般提示：
- 不要将 WOM 存储用于（元）数据（仅 ID/外键）
- 尝试在工作数据和元数据之间划清界限
- 为每个 参与者（行业、产品...）使用专用 table
- WOM 最好放在 XML 中
- 了解 (Finite) State Machines
- 了解 state pattern
- 了解 Business-Process-Modelling 和工作流程