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