好的,所以我想创建一个包含网站所有数据的数据库。但是,对于那些只存在一次的项目,这不是问题,我该怎么办?
例如,在主页上,用户经常更改介绍文本,如何将其存储在数据库中?主页上还有6个项目经常被用户更改。
我的想法是创建一个包含6个项目作为列的表格,表格只有一行。从数据库设计的角度来看,这可以吗?
答案 0 :(得分:1)
你可以这样做:
table PageContent
-----------------
varchar(10) Key
varchar(8000) Value
varchar(30) PageName //use an index for this column
您可以为这样的页面加载所有变量:
select * from PageContent where PageName = 'StartPage'
在您的代码中,您将检索一些您可以使用的集合:
Show(pageContents["Title"])
答案 1 :(得分:0)
假设六个项目都是相同的类型(在这种情况下是向网页提供内容的文本),我更喜欢具有ItemName和ItemValue VARCHAR列的设计。这使您可以在不改变数据库模式的情况下轻松地将方案扩展到七个项目(或更多)。
您也可以考虑将此材料保留在数据库之外。
答案 2 :(得分:0)
听起来效率不高,因为你必须得到所有项目的那一行。如果您持有的是文本或blob,请将每个项目放在其自己的行中。如果你正如你所说的那样,对项目进行频繁的更改,你基本上会一遍又一遍地更新同一行。
另一个考虑因素:你现在有6件物品。也许明天你会有8,19等。然后你必须经常改变桌子。因此,我建议使用2列表('id'或'type'列和'content'列)。
答案 3 :(得分:0)
基本上,您所听到的是两种解决方案之一:EAV解决方案或使用单行表。单行解决方案具有以下优点:
除非你要拥有数百个列,否则拥有数十个列并没有什么区别。
EAV结构肯定更具动感。如果这将支持站点程序集,那么无论何时在某处添加属性,都必须更改代码以使用该新属性。此外,使用EAV结构,您无法保证值将存在,也不能保证它将匹配来自另一个表的内容。
如前所述,EAV系统的最大优势在于它更具动态性。如果您的系统真的支持许多不同类型的站点,并且这些站点的站点设计者可能对数据属性的存储有不可预见的需求,那么EAV结构会更好。