在我公司的软件产品中，许多数据库表都使用了“display_order”字段。它是一个整数，控制页面上元素的显示顺序。
在我的内心深处，我觉得这是一种不好的做法。（或者至少，一个不太理想的设计选择）。但是，我无法向自己阐明为什么这是一种不好的做法。
到目前为止，我能想到的唯一原因是：
它将视图混合到模型中。
更改顺序是一项涉及许多不同行的潜在昂贵的数据库操作。
在许多情况下，如果您知道元素的顺序，那么表格可能足够小，以至于表格一开始就是浪费。例如，在我们的“状态”表中，状态应该是一个简单的硬编码数组，而不是一个单独的“查找”表。
是否有其他人有任何好的论据来避免在数据库设计中使用“display_order”字段？
在某些情况下，这是订购商品的最佳选择。
特别是 - 当项目没有自然顺序时，或者自然顺序不是程序可以轻松完成的事情（比如自然语言 - 音素）。
反之亦然，并且将成为反对此类字段的论点的“肉” - 如果项目确实具有可以轻松实现的自然顺序（数字，字母表），那么此类字段就没有位置。
这个讨论忽略了用户设置项目排序的任何要求 - 如果存在这样的要求，那么“display_order”字段就是要走的路。
我认为这是一个艰难的过程，但你能意识到这一点是件好事。我所反对的唯一论点是它模糊了系统组件角色之间的逻辑区别。
但是，我发现在很多项目中，数据是根据插入顺序返回的（由于自动递增的主键和基于源数据的字母/数字顺序运行插入的脚本）并且站点/其他软件使用这个排序作为一个隐含的假设。只有当您对数据进行更新会破坏默认排序时，人们才会说“看起来我需要在数据库中显示排序”
在我使用“显示顺序”的大多数实现中，它与弹出窗口中的导航/子导航有关。在这种情况下，由于客户通常没有专业知识或不需要接触代码或数据库，因此使用显示顺序和拖放被证明是最有效的设计。很多时候，客户希望在没有特别直观的顺序的情况下在页面上显示项目，或者选择以他们可以轻松操作的可互换顺序显示某些页面元素，而 display_order 专为此任务而设计，因此使用这说得通。
在许多情况下，如果您知道元素的顺序，那么表格可能足够小，以至于表格一开始就是浪费。例如，在我们的“状态”表中，状态应该是一个简单的硬编码数组，而不是一个单独的“查找”表。
作为一个数据库人，我不得不不同意这一点。您的状态涉及某种完整性约束的可能性很大。在这种情况下，将它们放在一个表中可以使维护（通常添加“仅添加一个”状态）成为插入一行的简单问题。
您也可以将这种事情实现为 CHECK 约束，但是更改它（添加“仅添加一个”状态）将意味着更改表，这通常意味着通过 QA 和测试进行往返。向表中添加一行通常不需要 QA 和回归测试。
但是您不能通过在应用程序代码中硬编码数组来实现参与完整性约束的状态。应用程序代码根本无法强制执行在所有应用程序和所有用户之间共享的约束（或视图排序）。只有 dbms 可以做到这一点。