直接问题:
设计用于存储页面上配置的 URL 的数据库表的最佳实践是什么。
我们的用例:
我们进行了设计讨论，但无法得出什么是正确的设计的结论。我们 正在编写一个页面，其中的 URL 嵌入到表格中。所以页面看起来像
....content(some text)...
a |b |c |d
text |url |url |url
text |url |url |url
text |url |url |url
....content(some text)...
这个想法是在数据库中配置这些 url，以便每次 url 更改时 url 更改都不需要部署。
EDIT> a,b,c,d 是表格标题。 a 部分下的内容将是普通文本，而 b,c,d 部分下的内容将是超链接。
考虑到这一切，表应该为此结构设计什么。我们考虑了两种模式:
(a,b(url),c(url),d(url)) #dependent on table design. advantage: written code would
#be very simple and would not be dependent on the number
#of entries in the table.(a simple for loop would
#suffice for presentation logic). Disadvantage: if table
#changes in future, this table is doomed.
#EDIT>a,b,c,d are place holders to represent that content
#represent the headers of table.
(id, url) #advantage: Generic enough to encompass any url.
#disadvantage: This would require presentation layer changes in
#case of new addition of new row.
#EDIT>id is just a number to identify this url and would be used to
#refer while identifying this from presentation layer.
我们无法断定哪一个更好，因为每个都有自己的权衡(直到我们错过了一些东西)。或者这些都不好。
我们使用 NoSql Store 和 Jsp 来编写前端(表示)逻辑。
编辑> 以下是表可能发生的更改类型:
- 添加新行(频繁)。
- 删除现有行(频繁)。
- 列的顺序可以更改(但很少)。
- 列数发生变化(非常罕见，不认为曾经发生过，但可能会发生)。
- 更改底层 URL(两种设计都支持，因此并不重要)。
这里主要关注的是由所考虑的任何一种设计引起的维护开销(无论是在演示还是后端方面)。
编辑2>
所以这个项目只是为现有的服务编写前端。我们不必过多处理所谓的应用程序状态。但是在某个网页上有一些 URL(嵌入在我提到的表中)，并且业务需求不是每次有人提出更改请求(例如更改现有 url 时)都部署(这段代码)最频繁的变更类型)。因此，关于 URL 的所有信息都将被移动到数据库中，并在页面加载时从网页进行查询(或者可能是预加载，这样我们就不会破坏页面的性能)。现在讨论的是为此用途设计一个合适的表格。
最佳答案
TL；博士:
表示层呈现某物:应用程序层的状态(一部分)。独立于呈现设计应用程序状态。
预期变化
通过提供 hides information 的状态(数据库/API)，最大限度地减少应用程序层更改对表示层(或其他用户)的影响。 。这意味着prioritize likely changes and offer an interface whose secret knowledege is which variant is current (pdf)。
例如，以下 API 变得更加通用，但允许在列表中进行越来越多的更改:“dog”、varchar(3)、varchar(n)、字符列表、字符串。相应的代码可能是: print "dog", for i=1..3 print s[i], for i=1..n print s[i], for s.iterator() print s.next(), s.print()。
更改越大，访问权限就越通用。因此，在变化的可能性和规模与通用性的模糊性和计算成本之间找到工程平衡。
应用层超越呈现
考虑一款棋盘游戏。棋盘上有玩家、分数、回合、规则和位置，其中一些是玩家所在的位置等。但是商店中的盒子可以有不同的图形、不同的物理 Material 、不同的标记、不同的文本格式、不同的语言；某些文本或图形不是翻译，而是类似物；视频版本有自己的演示，以命令代替 Action ；网络多人游戏版本可以同时进行多个演示。将演示与游戏状态分开。
首先为应用程序状态(“游戏”)正确设计一个数据库/API，独立于任何呈现(“盒子”)。将其体现在 DBMS 中。然后，演示文稿查询/访问该状态/API。决定应用程序状态中的 url 文本与 id，特别假设对演示没有任何影响(将显示什么或格式是什么或何时显示)。 (但是您还没有回复我对此的评论。)大概应用程序状态中有一个表 a-b-c-d，或者不存在，但它可以表示为对其他表的查询。确定这些表格和任何其他表格，具体假设与演示无关。 (但是您还没有回复我对此的评论。)该设计应该隐藏当前应用程序层实际上是哪些预期变体。
然后编写表示层来查询/访问该应用程序状态。
表示层的实现将有自己的状态。它可以将其中任何内容放入 DBMS 或任何其他资源中。 (但是您还没有回复我对此的评论。)不要将应用程序对 DBMS 的使用与表示层对 DBMS 的使用混淆。 DBMS 只是为两个主服务。即使其层决定其状态，也会将应用程序和表示表放入同一数据库。
...尽可能多
应用程序状态/API 设计始终部分基于要进行的查询/访问以及架构。关系数据库最大限度地减少了适当应用程序的这种情况。在非关系实现中，设计将更多地受到表示层的特定查询/访问的影响，而且还受到应用程序的所有用户的影响。
答案
由于表示层的原因，请尽可能不要将 a-b-c-d 或 url id 或其他应用程序状态放入数据库中。独立于表示层设计应用层状态/API。这应该让您能够详细回答您的问题。 (但你还没有回复我对此的评论。)
关于database-design - 用于在网页上存储 URL 的数据库表设计的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24093558/