这不完全是一个问题，但我只是在寻找关于这个问题的意见。
我在一家公司做我的第一份工作。他们要求我优化他们的 mysql db 全文搜索。
现在，一看到数据库结构，我就真的变脸了。
这是一个汽车零件数据库，它们有 1 个表和 3 列：ID、part_number、xml。
我只是愚蠢地不理解这一点，还是他们把所有的信息都放在了一个巨大的 xml 文本中，我把每个不同产品的所有信息都说了出来？我就是不明白，想澄清一下。难道他们没有将关于该产品的每个不同信息（例如：颜色、尺寸、制造商等）放在每个不同的列中吗？还是使用基于对象的非关系数据库（如 Mongo）？使用它来启用对 XML 文本的“全文”搜索以返回相关项目是一种“正常”的做法吗？
请赐教，要么我真的很愚蠢，不明白，要么DB完全是胡说八道。
提前致谢。
好吧，按照你描述的方式，它看起来确实有点愚蠢。在不了解数据结构的情况下很难说任何关于修改数据结构的事情，但我认为任何事情都比全文搜索更好。
他们遇到的问题是，不同部分的属性数量是一个永无止境的列表，其中一些对许多部分是通用的，而另一些则不是。如果您尝试为每个属性放置一列，那么您最终会得到数千列 - 在某些 RDBMS 中有一些技术可以处理 - 稀疏列/表。
另一种方法是将属性规范化到存储part_id、attribute、value的属性表中——这将成为一个非常大的键值表，并且基数会迅速增长——其中一些值可能是不同的类型，并且可能相当大。它们也会重复，因此您可以再次规范化，然后意识到您已经陷入了痛苦的性能和可怕的场景中，您有多个不同类型的值字段或必须存储变体数据类型。
最后的替代方法是 FTS 字段/存储 XML - 这是您发现有人选择的。
有人做出了选择，也许是您第一次在 RDBMS 中看到它，但可能不是最后一次 - 当您在关系存储中时 - 考虑一下您将如何以不同于原作者的方式来做（在 RDBMS 的限制内） .
为具有不同属性的项目存储属性信息总是一个令人讨厌的问题——我已经看到过去人们采用的所有三个选项。