直接问题：
设计用于存储页面上配置的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.
我们无法得出其中哪一个更好的结论，因为每一个都有自己的权衡(直到我们错过了一些东西(。或者这些都不好。
我们使用NoSqlStore和Jsp来编写前端(演示(逻辑。
EDIT>以下可能是表格可能发生的更改类型：
- 添加新行(频繁(
- 删除现有行(频繁(
- 列的顺序可以更改(但很少(
- 列数发生变化(非常罕见，不认为曾经发生过，但可能发生(
- 更改基础URL(这两种设计都固有支持，因此不重要(
这里主要关注的是维护开销(从演示和后端角度来看(，这将由所考虑的任何一种设计引起。
编辑2>
因此，这个项目只是为已经存在的服务编写前端。我们不必过多地处理所谓的应用程序状态。但在某个网页上有一些url(嵌入在我提到的表中(，业务要求是每次有人提出更改请求时都不要部署(这段代码((比如更改现有url，这是最常见的更改类型(。因此，URL上的所有信息都将被移动到数据库中，并在页面加载时从网页中查询(或者可能是预加载的，这样我们就不会影响页面的性能(。现在讨论的是为这种用途设计一个合适的表。
TL；DR:
表示层表示一个东西：(应用层状态的一部分(。独立于演示文稿设计应用程序状态。
预计变化
通过提供隐藏信息的状态(数据库/api(，最大限度地减少应用程序层更改对表示层(或其他用户(的影响。这意味着优先考虑可能的更改，提供了一个接口，其秘密知识是当前的变体(pdf(。
例如，以下api变得更通用，但允许更多&列表中还有更多的更改："dog"、varchar(3(、varchar(n(、list of char、string。对应的代码可能是：print"dog"，对于i=1..3 print s[i]，对于i=1..n print s[i].，对于s.迭代器((print s.next((，s.print((.
更改越大，访问就越通用。因此，在变化的可能性和大小与模糊性和通用性的计算成本之间找到一个工程平衡。
应用程序层超越了演示
考虑一个棋盘游戏。棋盘上有玩家、分数、回合、规则和位置，其中一些是玩家所在的位置等。但商店里的盒子可能有不同的图形、不同的物理材料、不同的代币、不同的文本格式、不同的语言；有些文本或图形不会是翻译，而是类似的；视频版本有自己的呈现方式，用命令代替动作；网络多人游戏版本同时具有多个演示。将演示与游戏状态分开。
首先，为应用程序状态("游戏"(设计一个独立于任何演示("盒子"(的数据库/api。将其体现在DBMS中。然后，一个演示查询/访问该状态/api。决定应用程序状态下的url文本与id，特别是假设不考虑演示(将显示什么或格式或何时显示(。(但你还没有回应我对此的评论。(假设有一个表a-b-c-d处于应用程序状态，或者没有，但它可以表示为其他表的查询。决定那些表和任何其他，特别是假设不考虑演示。(但你还没有回应我对此的评论。(这个设计应该隐藏当前应用层实际是预期的变体中的哪一个。
然后编写表示层以查询/访问该应用程序状态。
表示层的实现将有自己的状态。它可以将其中的任何一个放入DBMS或任何其他资源中。(但你还没有回应我对此的评论。(不要把应用程序对DBMS的使用与表示层对它的使用混为一谈。DBMS只是为两个主机服务。即使其层决定其状态，也会将应用程序表和表示表放入同一数据库中。
。。。尽可能多
应用程序状态/api的设计总是部分基于要进行的查询/访问以及体系结构。对于适当的应用程序，关系数据库可以最大限度地减少这种情况。在非关系实现中，设计将更多地受到表示层的特定查询/访问的影响，也会受到应用程序的所有用户的影响。
答案
由于表示层的原因，尽可能不要将a-b-c-d或url id或其他应用程序状态放入数据库中。独立于表示层设计应用层状态/api。这样你就可以详细地回答你的问题了。(但你还没有回应我对此的评论。(