这个想法是针对一个反向拍卖平台，用户在某些服务上发布拍卖，并且提供商会根据他们的优惠对其进行竞标。
我应该拆分桌子吗？例如，拍卖可以用于新服务或替换现有服务，因此存在特定于每个选择的问题。
我应该将这些列移动到该选项的单独表中吗？
这是我到目前为止所提出的一个图表： Database Diagram image
我在这里走在正确的轨道上吗？
我应该在列表中使用哪种数据类型，在这些列中会有一个可供选择的选项列表在拍卖表单中？例如， cash_back 会为用户提供以下选项范围：
是否使用字符串为此列使用相应的字符串或是否为选项创建新表并在此表中使用option_id作为外键？
答案 0 :(得分：0)
我认为值得讨论Rails哲学和数据库设计。
正如我经常说你可以为你的应用程序建立一个数据库，或者你可以拥有一个数据库应用程序。在后者中，数据库设计很重要。在前者中，它通常遵循应用程序设计。
这意味着您可能（假设这是一个Rails应用程序）根本不想设计您的数据库。你想要做的是设计你的应用程序对象模型，让Rails设计你的数据库。你不会以这种方式获得一个出色的数据库设计，但它已经足够好了。
权衡的是，当你这样做时，你经常最终得到应用程序有效拥有的数据库，让其他应用程序添加或修改数据库中的数据可能不安全。此外，提供非常好的报告可能更难，但是你把大部分时间放在哪里会更好地优化（你的主要应用程序）。
TL; DR：如果你想为你的应用程序建立一个数据库并使用Rails或Django，那么就不要再考虑数据库设计了，但要意识到虽然今天优化了一些路径，但它会使许多其他事情变得更难。
