设计者完成的项目，不能只有设计者本人看懂。企业需要积累，接手者必须能够理解前任留下的成果。判断“标准”的一个原则是：一个新人能不能只依靠规则，识别一套不属于自己的项目。
从需求出发：企业管理数据的目的
全局主键
企业希望每名员工创建的资源都能沉淀为企业资源，而不是人员离开后变成无法接手的数据黑洞。
检索和识别是基本需求，检索最重要的是 key 的设置。如果流水号分发依赖联网，用户出差、居家、请假或加班时都能获得服务，自然最好。但如果无法持续联网，或者需要考虑必须断网的场景，就要解决离线创建唯一 key 的问题。工号加流水号，或者 UUID，都是可行的离线 key。
UUID 是获得唯一键的数学方法，但缺点一是太长，32 个字符无法口传，只能复制；缺点二是不够具象。
流水号加工号具有一定现实意义，UUID 做不到。UUID 的唯一优点是数据库友好，只需要一个字段。
流水号加工号需要两个字段，但在巨型数据库中检索消耗会急剧增加。如果采用字符串拼接，同样只需要一个字段，因此更推荐。
云服务是否需要考虑单机问题，本质上是用户满意度问题。从用户角度看，网络服务无网不可用是理所当然的，只需要判断是否存在必须单机运行的场景。
服务器提供的不是服务，而是规矩。规矩由人制定、由人执行：制定时需要适配工作并保留灵活变化的空间；执行时则通过代码统一铺开、强制执行。
项目名设置
项目名可以考虑流水号、工号、UUID、名称和其他信息。
前缀扩展：很多企业无论图纸编号还是其他标识，都喜欢加入企业前缀，例如“北京岚月”可以用“LY-项目1”。这没有太多实际用途，但属于常见偏好。
量化的权限值：用于表达谁可读、谁可改。例如项目 A 的权限值是 80，用户 B 的权限值是 50，B 就可以修改。这是一种可量化的权限判断方式。
休眠：这是纯技术考虑，用于提高数据库检索速度，并压缩一些长期不用的数据。
创建时间、负责人和描述按字面含义使用，不再展开。
数据表实现：明文部分包括主键、工号加流水号、前缀扩展和名称；密文部分包括权限、休眠、创建时间、负责人和描述。
文件保存规则：找得到文件
为每个项目创建一套固定的文件夹结构。在单机环境中，文件夹是最直观的识别方法。
- 文件夹层级固定并尽量扁平，让用户无论是否了解规则，都能一眼找到目标。
- 需要哪些文件夹，由管理者预设。
- 除技术必需的文件夹外，其他文件夹允许管理者删改。
- 规则确定后由代码自动创建，减少用户随意创建文件夹、导致外人无法找到文件的概率。
上图中的 SW、Prod、Back 是 SWTDO 的固定文件夹，分别保存设计原始文件、生产文件和备份文件。其他文件夹可以删除，也可以修改。
文件存在，不等于资源可复用。
找不到文件，就是资源黑洞的开始，也是人员流动时资料丢失的第一步。
文件名的设置考虑要点
下文的前提是文件名必须包含全局主键。
企业对文件名的设置方式很多，不存在绝对通用、适用于所有企业的规则。SWTDO 的目标不是替企业制定唯一规则，而是提供程式化方式，让企业可以自定义规则。
SWTDO 把文件名拆分成不同元素，用户通过排列组合这些元素来实现自己的命名需求。
元素按大类划分：
- 固定式：用户输入什么就输出什么。例如输入 Cus1 就输出 Cus1，输入空格就输出空格，输入中横线就输出中横线。
- 函数式：根据当前信息输出。例如短日期会输出当天日期，项目名是减速箱时就输出“减速箱”。
- 判断式：根据文件类型或位置输出。例如零件输出 P，装配输出 U，文件位于装配第 3 级子装时输出 3。
- 调用提取式：从文件属性中提取信息，前提是属性遵循唯一数据源。属性调用本身也有多种方式，因此最终不是 4 种组合，而是 4 种方式与 3 种方式的二次拼接。
基于这种元素拼接方式，目前还没有遇到无法实现的企业文件名格式。这里唯一缺少的是部分 SolidWorks 专用函数，例如材料，但一定可以找到对应的实现方式。以前 BOM 中曾经使用过零件号这类专用提取函数。
顺便说明，MakeOrBuy 这种分类略显粗糙。Make 还可能包括焊接厂加工、注塑厂加工、机械加工，甚至布料厂加工。
例如车衣设计、太阳能背包设计和无人机防弹伞设计，这些案例说明制造分类非常多样。粗糙的大类不能解决分发问题，最终仍要允许用户自定义。与其替用户固定字段，不如提供定义字段的能力，这一点将在 BOM 标准化中详细说明。
