我一直在研究很多，普遍的共识是尽可能避免在数据库中序列化哈希，但是我的设计适合这种结构，所以我希望得到一些意见和/或建议。这是场景：
我有一个模型/表格:products，其中包含金融产品。每个产品has_many的投资策略，我最初存储在一个单独的:strategies模型/表格中。由于每个产品都有完全不同的策略，并且每个策略都有不同的属性，因此将每个策略的属性操作到规范化、一致的列中变得非常困难（而且很棘手）（以至于我有一些产品我根本无法添加到应用程序中） . 此外，策略的属性有时会根据分配给该策略的金额而改变。
为了解决这个问题，我正在考虑:strategies完全删除模型/表，并简单地在我的模型/表中添加一个策略列:products。新列将包含每个产品策略的多维散列。从数据存储的角度来看，此选项提供了极大的灵活性。
我的主要问题是，以这种方式重组我的数据库是否会丢失任何功能？有时我需要根据产品的策略属性来搜索产品，而且我已经读到在多维散列中搜索充其量是困难的。这被认为是不好的做法吗？有没有我没有考虑过的第三种解决方案？
在此设计中使用多个表滚动的优点是您可以利用数据库通过约束、函数和触发器来保护您的数据。数据库是您可以 100% 放心地保护客户数据的唯一地方。近年来，这些久经考验的真实技术已经失去了光彩，对于那些不了解它们的人来说，它们被认为是繁琐和/或不必要的。
由于 nosql 数据库的流行，关系数据库中基于散列的存储目前正在迅速变化，但是，传统上很难通过这种实现来完全保护您的客户数据免受数据库的影响。因此，应用程序层是这种保护的大部分所在。话虽如此，这正在被创新，也许有一天他们会解决它。
将哈希用作表中的列的最大优势是您可以在找出问题的同时更快地起床并继续前进。此外，您可以更轻松地进行旋转，因为大多数修改都是在应用程序层中即时进行的。
如果您在关系数据库中使用基于散列的存储，则全文搜索和复杂查询也可能会更加困难。
一般的经验法则是，如果您需要安全的数据，或者有一些复杂的报告要做，那就去关联。想想一个大型金融服务类型的应用程序；）否则，如果您构建一个更具社交性、数据显示风格的应用程序，或者只是模拟一些事情，那么序列化哈希列没有任何问题。最重要的是记住编写测试，这样如果你选错了，你就可以更自信地重构！
我的 0.02 美元
我很想知道您选择了哪个决定以及结果如何。