在我们的应用程序中,我们目前有一个包含大约 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
,那么1
之后的所有order_number
都必须下移以说明这一点。总的来说,维护起来似乎有点挑战性。
谁能帮助我了解最好的架构类型是什么?或者关于保留设置列表顺序的方法的任何想法?
这将归结为您的软件需要如何与数据交互。 像往常一样,在这些情况下询问"最佳"方式,答案是"这取决于! 细节决定成败。 以下是三个选项,选择哪个选项应取决于您的使用模式需求:
-
考虑RDBMS和模式的"正确"方法确实可以通过辅助表或额外列将排序值或排名附加到每一行。 这允许您实现诸如"没有两行可以具有相等的排名(
UNIQUE(...)
)"之类的约束,并且您可以让数据库的优化器和缓存机制在应用程序代码中保存一些详细信息。 另一方面,它意味着每当用户重新排序其设置时,都会进行许多写入操作。 然后是标准的工程"epsilon"问题:性能重要吗? 当然,重写所有这些行是低效的,但是如果每个用户只做一两次,它实际上会带来问题吗? -
同时,您可以尝试另一个建议(@SloanThrasher击败我们!),它只是在需要时使用排序更新单个文本行(称为CSV或JSON或...)。 但是,这会将负担从架构定义转移到应用程序代码,以确保永远不会留下过时或不正确的引用(例如,删除设置、更新设置、创建新设置)。
-
我看到实现的另一个很好的选项是有一个排序列或辅助表 - 完成由模式处理的ACID详细信息 - 但排名实际上是一个排序的二叉树。 在这种情况下,用户不断大量更新排名,因此围绕 SELECT 语句的应用程序代码所产生的额外负担被认为是值得的。
你衡量,支付你的钱,做出你的选择,然后再次衡量。 祝你好运! ;-)