Globals、对象还是 SQL 表？

IRIS数据建模的决策框架。

关于选用哪种模型的决策涉及多方面因素。 我建议分别对每个维度进行评分，然后将结果相乘。 根据您偏好的评分方式，得分最高或最低的模型胜出。 我看到了这些维度，但具体方面可能会使列表进一步扩展。

• 开发人员在 SQL、面向对象和Globals方面的技能
• 维护人员和运维人员在 SQL、面向对象和Globals方面的技能
• 与 SQL、面向对象、Globals相关的数据文化
  • 我曾遇到过完全拒绝使用SQL的客户
• 开发和测试所需的时间
• 需存储在SQL、面向对象和Globals中的结构复杂度
• 访问速度
• 存储消耗
• 数据类型和质量检查
• 对变更和增强的灵活性…… 
• 更多

SQL的技术维度

• 若仅包含简单列，生成 CREATE TABLE 语句的速度会很快

  • 但添加外键或引用其他表可能会带来挑战

• 访问速度仅对大型表重要，且受以下因素影响

• 存储空间消耗

  • 您可以将其完全交给代码生成器处理，几乎无需干预
  • 在后台，每张表都对应一个 Object 类
  • 以及一组可供使用的Globals

• 要提高访问速度，需要巧妙地建立索引

• 您可以对标准数据类型进行全面检查

• 灵活性

  • 仅需添加一列便十分简单
  • 更复杂的更改可能会让人头疼不已

对象的技术维度

• 利用现有的工具，创建一个对象类是一件轻而易举的事。

• 添加索引或引用其他对象是标准功能

• 访问速度仅在处理大型对象集时才显得重要

• 存储占用

  • 这由代码生成器来处理 
  • 但存储定义是你的 Object 的一部分
  • 对于设计者与以下内容相关的决策，它完全自由
  • 将要使用的Globals集

• 你可以获得对标准数据类型的全面检查

  • 但可以创建具有特定规则的自定义数据类型

• 灵活性

  • 添加或修改属性非常简单
  • 内容检查规则也是如此 

技术层面全局变量

• 创建一个纯粹的 Globals 数据存储需要一些设计工作

• 您可以完全自由地设计细粒度的存储方案

• 所有特定的技巧都可供您自由运用

• 访问速度仅取决于您的设计能力

• 存储消耗

  • 由您决定，一切尽在您的掌控之中

• 访问速度的提升取决于您压缩数据的能力

  • 仅供说明。 

    • 使用整数代替文字描述的颜色
    • 空元素根本不会被存储，也没有占位符

• 检查数据类型和质量是你的职责

• 灵活性

  • 在实践中几乎没有限制
  • 所有巧妙或“小伎俩”均可使用 

总结

你将面对一个分层结构模型

• SQL
  • 对象
    • Globals

你必须决定从哪个层级进入 在更深的层级上，你将获得更大的自由度 但这意味着更多的工作量和更大的责任 请权衡：为实现目标所付出的额外努力是否值得 而且，复杂度越高，你与该项目的绑定时间就越长。  

现在轮到你了