jan*_*jan 5 java database constants
什么是性能方面的最佳解决方案和"可读性/良好的编码风格"来表示DB层上的(Java)枚举(固定的常量集)关于整数(或一般的任何数字数据类型)与字符串的关系表示.
警告:有些数据库系统直接支持"枚举",但这需要保持数据库枚举定义与业务层实现同步.此外,这种数据类型可能并非在所有数据库系统上都可用,并且语法可能不同=>我正在寻找一种易于管理且易于在所有数据库系统上使用的简单解决方案.(所以我的问题只是解决了Number vs String表示.)
在我看来,常量的Number表示非常有效(例如,仅消耗两个字节作为整数),并且在索引方面很可能非常快,但难以阅读("0"与"1"等). .
字符串表示更具可读性(与"0"和"1"相比,存储"已启用"和"已禁用"),但消耗的存储空间很多,并且在索引方面很可能也较慢.
我的问题是,我是否错过了一些重要方面？您建议在数据库层上使用枚举表示法.
非常感谢你!
在大多数情况下，我更喜欢使用简短的字母数字代码，然后使用包含扩展文本的查找表。必要时，我会从数据库表动态地在程序中构建枚举表。
例如，假设我们有一个字段应该包含交易类型，可能的值为销售、退货、服务和分期付款。我将创建一个包含代码和描述的交易类型表，使代码可能为“SA”、“RE”、“SV”和“LY”，并使用代码字段作为主键。然后在每条交易记录中我都会发布该代码。这比记录本身和索引中的整数键占用的空间更少。它的具体处理方式取决于数据库引擎，但它的效率不应显着低于整数键。而且由于它具有助记性，因此非常易于使用。您可以转储记录并轻松查看值是什么，并且可能记住哪个是哪个。您可以在用户输出中显示无需翻译的代码，并且用户可以理解它们。事实上，这可以为您带来比整数键更高的性能：在许多情况下，缩写对用户来说是有好处的——他们通常希望缩写保持显示紧凑并避免滚动——所以您不需要加入事务表获得翻译。
我绝对不会在每条记录中存储长文本值。就像在这个例子中一样，我不想放弃交易表并存储“Layaway”。这不仅效率低下，而且很可能有一天用户会说他们希望将其更改为“Layaway sale”，甚至是“Lay-away”之类的细微差别。然后，您不仅需要更新数据库中的每条记录，还必须在程序中搜索该文本出现的每个位置并进行更改。此外，文本越长，程序员就越有可能拼写错误并产生模糊的错误。
此外，事务类型表提供了一个方便的位置来存储有关事务类型的附加信息。永远不要编写这样的代码：“如果whatevercode='A'或whatevercode='C'或whatevercode='X'那么......”无论是什么使这三个代码与所有其他代码有所不同，请为将其放入交易表中并测试该字段。如果您说“嗯，这些都是与税务相关的代码”或其他什么，那么可以创建一个名为“tax_lated”的字段，并根据需要将每个代码值设置为 true 或 false。否则，当有人创建新的交易类型时，他们必须查看所有这些 if/or 列表，并找出该类型应该添加到哪些交易类型以及不应该添加到哪些交易类型。我读过很多令人困惑的程序，在这些程序中我必须弄清楚为什么某些逻辑应用于这三个代码值而不是其他代码值，并且当您认为第四个值应该包含在列表中时，很难判断它是否是缺失是因为它在某些方面确实不同，或者程序员犯了错误。
我不创建转换表的唯一类型是当列表非常短，没有额外的数据要保留时，并且从宇宙的本质可以清楚地看出它不太可能改变，因此可以安全地保存值硬编码。就像真/假或正/负/零或男性/女性。（嘿，即使是最后一个，虽然看起来很明显，但有人坚持认为我们现在包括“变性”之类的内容。）
有些人教条地坚持每个表都有一个自动生成的顺序整数键。在许多情况下，此类键是一个很好的选择，但对于代码列表，由于上述原因，我更喜欢短字母键。