在域 table 具有自由文本的 "Other" 选项的情况下，数据库规范化的最佳做法是什么？

Question

我目前正在为我的公司规范化一个数据库，我在这个数据库中经常看到的一种模式是使用域查找 table 来获取值，但也允许 "Other" 并将结果存储在单独的列中。

我的问题是是否有更清晰的表示方式？对于上下文，我遵循高达 5NF 的正常形式和域密钥形式。我看到的更大的问题是在某些 table 中这种模式重复了多次，所以我们有一个 table 如下所示：

╔══════════════╦══════════════════╦═════════════════════╦═══════════════════╦══════════════════════╗
║ appliance_id ║ location_type_id ║ other_location_type ║ appliance_type_id ║ other_appliance_type ║
╠══════════════╬══════════════════╬═════════════════════╬═══════════════════╬══════════════════════╣
║          123 ║                1 ║ {null}              ║                13 ║ Freestanding Boiler  ║
║          124 ║               13 ║ Annex               ║                 1 ║ {null}               ║
╚══════════════╩══════════════════╩═════════════════════╩═══════════════════╩══════════════════════╝

例如，location_type_id & appliance_type_id 的 13 在相关查找 table 中是 "Other"。

例如，位置类型 table 看起来像这样：

╔═════╦═══════════════╗
║ id  ║ location_type ║
╠═════╬═══════════════╣
║ 1   ║ Living Room   ║
║ 2   ║ Kitchen       ║
║ ... ║ ...           ║
║ 13  ║ Other         ║
╚═════╩═══════════════╝

这很可能是最好的解决方案（尽管我可能会将位置和设备类型分成不同的 tables）尽管我希望得到一些更有经验的人的关注，这是我第一次处理完整的自上而下的重组，我渴望从一开始就把它做好。

谢谢！

Answer 1

讨论过后，我们将按照建议进行，进行文本扫描并使用它来填充我们的查找，然后我们将尝试不鼓励使用自由文本字段进行查找，存储暂时将值放在单独的 table 中，这样我们就不会弄乱我们的主要 tables.

在域 table 具有自由文本的 "Other" 选项的情况下，数据库规范化的最佳做法是什么？

What's best practice for normalisation of DB where a domain table has an "Other" option for free text?

mysql

sql

database-design

database-schema

database-normalization