2

直接问题：

设计用于存储页面上配置的 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 来编写前端（演示）逻辑。

编辑>以下可能是表可能发生的更改类型：

  1. 添加新行（频繁）。
  2. 删除现有行（频繁）。
  3. 列的顺序可以改变（但很少见）。
  4. 列数变化（非常罕见，认为从未发生过但可能发生）。
  5. 底层 URL 的更改（两种设计都支持，所以不重要）。

这里主要关注的是维护开销（在演示和后端角度），这将由所考虑的任何一种设计引起。

编辑2>

所以这个项目只是为已经存在的服务编写前端。我们不必过多处理所谓的应用程序状态。但是在某个网页上，有几个 URL（嵌入在我提到的表中）并且业务要求不是每次有人提出更改请求时都部署（这段代码）（例如更改现有 url，即最常见的变化类型）。因此，所有关于 URL 的信息都将被移动到数据库中，并在网页加载时查询（或者可能是预加载的，这样我们就不会破坏页面的性能）。现在这个讨论是关于为此用途设计一个合适的表。

4

1 回答 1

2

TL;博士：

表示层呈现某种东西：（部分）应用层的状态。独立于演示设计应用程序状态。

预测变化

通过提供隐藏信息的状态（数据库/api），最大限度地减少应用层更改对表示层（或其他用户）的影响。这意味着优先考虑可能的更改并提供一个界面，其秘密知识是哪个变体是当前的（pdf）。

例如，以下 api 变得更加通用，但允许在列表中进行更多和更多的更改：“dog”、varchar(3)、varchar(n)、char 列表、字符串。对应的代码可能是： print "dog", for i=1..3 print s[i], for i=1..n print s[i], for s.iterator() print s.next(),短跑（）。

变化越大，访问越通用。因此，在变化的可能性和大小与模糊性和通用性的计算成本之间找到工程平衡。

应用层超越表现

考虑一个棋盘游戏。棋盘上有玩家、分数、回合、规则和位置，其中一些是玩家所在的位置等。但商店中的盒子可以有不同的图形、不同的物理材料、不同的令牌、不同的文本格式、不同的语言；一些文本或图形不是翻译而是类似物；视频版本根据命令替换动作有自己的演示；联网的多人游戏版本同时具有这样的多个演示文稿。将呈现与游戏状态分开。

首先正确地为应用程序状态（“游戏”）设计一个独立于任何演示（“盒子”）的数据库/api。在 DBMS 中体现它。然后演示文稿查询/访问该状态/api。决定应用程序状态中的 url 文本与 ids，特别是假设没有关于演示的内容（将显示什么或格式将是什么或何时）。（但你没有回应我对此的评论。）大概有一个表 abcd 处于应用程序状态，或者没有，但它可以表示为对其他表的查询。决定那些表和任何其他特别假设没有关于演示的表。（但你还没有回复我对此的评论。

然后编写表示层以查询/访问该应用程序状态。

表示层的实现将有自己的状态。它可以将其中的任何内容放入 DBMS 或任何其他资源中。（但您还没有回应我对此的评论。）不要混淆应用程序对 DBMS 的使用与表示层对它的使用。DBMS 只是为两个主服务器服务。即使它的层决定了它的状态，也将应用程序和表示表放入同一个数据库中。

...越多越好

应用程序状态/api 设计总是部分基于要进行的查询/访问和架构。对于适当的应用程序，关系数据库将其最小化。在非关系实现中，设计将更多地受到表示层的特定查询/访问以及应用程序的所有用户的影响。

答案

尽量不要出于表现层的原因将 abcd 或 url ids 或其他应用程序状态放入数据库中。独立于表示层设计应用层状态/api。这应该让您能够详细回答您的问题。（但你还没有回复我对此的评论。）

于 2014-06-07T06:17:06.350 回答