Question

直接问题：

设计用于存储页面上配置的网址的数据库表的最佳做法是什么。

我们的用例：

我们进行了设计讨论，无法得出正确设计的结论。我们正在编写一个页面，其中包含嵌入表格中的URL。所以页面看起来像

 ....content(some text)...
 a     |b     |c     |d
 text  |url   |url   |url
 text  |url   |url   |url
 text  |url   |url   |url
 ....content(some text)...

我们的想法是在数据库中配置这些网址，以便每次网址更改时网址更改都不需要部署。

EDIT＆gt; 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来编写前端（表示）逻辑。

编辑＆gt;以下内容可以是表中可能发生的更改类型：

添加新行（频繁）。
删除现有行（频繁）。
列的顺序可以更改（但很少见）。
列数发生变化（非常罕见，不要认为曾经发生但可能发生）。
更改基础网址（两种设计都固有支持，因此不重要）。

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

EDIT2＆GT;

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

Answer 1

<强> TL; DR：

表示层呈现 :(部分）应用程序层的状态。设计应用程序状态独立于演示文稿。

预期变更

通过提供hides information的状态（数据库/ api），最大限度地降低表示层（或其他用户）上应用程序层更改的影响。这意味着prioritize likely changes and offer an interface whose secret knowledege is which variant is current（pdf）。

例如，以下apis变得更通用但允许更多＆amp;列表中有更多变化：＆＃34; dog＆＃34;，varchar（3），varchar（n），char列表，字符串。相应的代码可能是：print＆＃34; dog＆＃34;，i = 1..3 print s [i]，i = 1..n print s [i]，s.iterator（）print s .next（），s.print（）。

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

应用层超越了演示文稿

考虑棋盘游戏。在棋盘上有玩家，得分和转弯以及规则和位置，其中一些是玩家所在的位置等。但是商店中的盒子可以具有不同的图形，不同的物理材料，不同的标记，不同的文本格式，不同的语言;一些文字或图形不是翻译而是类似物;视频版本有自己的演示文稿，命令取代动作;联网的多人游戏版本同时具有多个演示文稿。单独介绍游戏状态。

首先为应用程序状态（＆＃34;游戏＆＃34;）正确设计数据库/ api，而不管任何演示文稿（＆＃34;框＆＃34;）。在DBMS中体现它。然后演示文稿查询/访问state / api。在应用程序状态中确定url text vs ids，特别是假设没有关于表示（将显示什么或格式将是什么或何时）。（但是你还没有对我的评论做出回应。）大概是应用程序状态中有一个表a-b-c-d或者没有表，但它可以表示为其他表的查询。决定那些表格和其他任何明确假设演示文稿。（但是你没有回复我的评论。）该设计应该隐藏当前应用层实际上是哪种预期变体。

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

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

...尽可能

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

答案

出于表示层的原因，尽量不要在数据库中放置a-b-c-d或url id或其他应用程序状态。独立于表示层设计应用程序层state / api。这应该让你能够详细回答你的问题。（但你没有回复我的评论。）

设计用于在网页上存储URL的数据库表的最佳实践

1 个答案: