Question

在我们的应用程序中，我们目前有一个大约150个用户设置的列表。这些以前是硬编码的。硬编码的“表”看起来像这样：

[ old settings ]
----------------
setting_key    (string)
setting_label  (string)
checked        (0 / 1)

每个用户在mongo中都有一个条目，它本质上是一个包含这些值的巨型数组。由于用户可以选择设置显示的顺序，因此通过更新阵列结构来保留用户设置的顺序。此外，如果用户更改了setting_label，则会更新其setting_key的条目。这只允许用户重命名标签。

我们目前正在尝试重构所有这些用户设置，以摆脱硬编码巨型设置结构，并在用户可能只更改一个设置时不得不更新每一条信息。为此，我们设置了以下MySQL模式：

[ settings ]  --> the master list of settings that each user has
------------
setting_id        (int, auto-increment, primary key)
setting_key       (varchar)
setting_label     (varchar)

[ user_settings ] --> custom settings that override the default setting_id
-----------------
user_setting_id    (int, auto-increment, primary key)
user_id            (int)
setting_id         (int, foreign key references settings.setting_id)
user_label         (varchar)

直到我们意识到我们仍然必须以某种方式保留设置的顺序。并允许用户更改该顺序。

我们考虑过这样制作settings_order表：

[ settings_order ] --> user_id has settings in a specific order
------------------- 
user_id       (int)
setting_id    (int, foreign key referencing settings.setting_id)
order_number  (int)

问题是，如果默认情况下我有150个设置，则表示order_number将介于0和150之间，并且似乎是硬编码的。如果用户将order_number 150移至order_number 1，那么order_number之后的所有1都必须转移到帐户为了这。总的来说，维护似乎有点挑战。

任何人都可以帮助我理解这种模式的最佳类型是什么？或者有关于保留设置列表顺序的方法的任何想法？

Answer 1

这将归结为您的软件需要如何与数据交互。像往常一样，在询问“最佳”方式的情况下，答案是“这取决于！细节很重要”。这里有三个选项，您选择的应该取决于您的使用模式需求：

考虑到RDBMS和模式的“正确”方法可能确实通过辅助表或额外列将排序值或排名附加到每一行。这允许您实现诸如“没有两行可以具有相同的排名（UNIQUE(...)）”之类的约束，并且您可以让DB的优化器和缓存机制在您的应用程序代码中保存一些细节。另一方面，每当用户重新排序其设置时，它意味着许多写操作。然后是标准工程“epsilon”问题：性能是否重要？当然，重写所有这些行是低效的，但如果每个用户只做一次或两次，它实际上是否存在问题？
与此同时，您可以尝试另一个建议（@SloanThrasher击败我们！）只需更新单个文本行（称为CSV或JSON或...），并在需要时使用排序。这会将架构定义的负担转移到应用程序代码，但是要确保永远不会留下过时或不正确的引用（例如，设置已删除，设置已更新，新设置已创建）。
我见过的另一个选项实现效果很好的是有一个排序列或辅助表 - 完成由模式处理的ACID细节 - 但排名实际上是一个排序的二叉树。在这种情况下，用户不断更新排名，因此围绕SELECT语句的应用程序代码所带来的额外负担被认为是值得的。

你衡量，支付你的钱，做出你的选择，并再次采取措施。祝你好运！ ; - ）

如何为可以具有任意顺序的用户设置构建MySQL架构

1 个答案: