标签: denormalization

而试图找出如何标记一个博客帖子有一个SQL语句这里,下面的念头闪过我的脑海:使用关系表tag2post通过ID引用标记,如下恰恰是没有必要的:

tags
+-------+-----------+
| tagid | tag       |
+-------+-----------+
|     1 | news      | 
|     2 | top-story | 
+-------+-----------+

tag2post
+----+--------+-------+
| id | postid | tagid |     
+----+--------+-------+
|  0 |    322 |     1 |
+----+--------+-------+

为什么不使用以下模型,您可以在其中索引标记本身如下？认为标签永远不会被重命名,但是添加和删除,这可能有意义,对吗？你怎么看？

tag2post
+----+--------+-------+
| id | postid | tag   |     
+----+--------+-------+
|  1 |    322 | sun   |
+----+--------+-------+
|  2 |    322 | moon  |
+----+--------+-------+
|  3 |   4443 | sun   |
+----+--------+-------+ …

我有几乎非规范化的现有表.事物列表状态,类型,国家等没有查找表...这个原始设计只是为了简化应用程序对数据库的访问,因此这种非规范化没有性能原因.

这导致了包含大量重复数据的表格,我想通过为各种状态/类型/国家/地区列引入查找表来正确规范化.

是否有一些我可以在数据库(oracle)中做到这一点,对客户端保持透明？应用程序将继续执行插入操作,但数据库会将事物映射到幕后的正确查找表.

我一直在尝试使用可以进行映射的视图和触发器的组合,但感觉应该有更自动的方法来执行此操作.

我正在尝试为新表准备数据,该表与现有表中的数据相同但是非规范化.我有一个简单的场景,但我的想法是以最有效的方式返回结果

它基于以下简化方案:

Table X   | Table y
id        | id    Identifier  Value
123       | 123   1           A
          | 123   2           B

与表XI中的其他字段一起需要我的查询返回:

123 A B

我考虑过:

解决方案一

select 
id,
(select Value...),
(select Value...)...

解决方案二:

select id,
y1.Value,
y2.Value
from x, y y1, y y2...

解决方案三:使用PL/SQL并迭代游标

解决方案四:将y提取到两个表identifyyer1和identifier2(可能使用触发器)并在查询中连接这些表

由于这个或那个原因,这些解决方案中的每一个都有一个主要的缺点,我确信一个词可以让我想起一个解决这个问题的概念

我们网站的一部分要求用户询问20个关于他们自己的多项选择题("个人资料").网站的这一部分将经常被查看,并偶尔更新.该网站预计会产生大量流量,因此正在考虑尝试和准备性能问题.

我可以看到将这三种存储方式存储在数据库中:

1. 为每个问题创建1个表,每个表都有QuestionID和Answer,然后是CustomerInfo表来存储配置文件数据,外键映射到问题.

2. 问题,Question_Type和Answers表.把所有东西都塞进这些结构中.我在这里特别关注更新配置文件所需的20个左右的插入.这是否会在高流量时受到性能影响？

3. 非规范化单表,每个问题一个字段,在HTML和/或C#对象中硬编码答案代码.

我倾向于#2或#3.您认为什么是最佳解决方案？

我有下locations表:

----------------------------------------------------------
| ID | zoneID | storeID | address | latitude | longitude |
----------------------------------------------------------

和phones表:

-----------------------
| locationID | number |
-----------------------

现在,请记住,对于任何捐赠商店,最多可以有五个电话号码.订单无关紧要.

最近我们需要添加另一个表,其中包含商店相关信息,其中还包括电话号码.

现在,对于这个新表不适用locationID,因此我们无法将电话存储在上一个电话表中.

保持数据库规范化最终需要2个新表和总共4个连接来检索数据.对它进行非规范化将使旧表呈现如下:

----------------------------------------------------------------------------------
| ID | zoneID | storeID | address | latitude | longitude | phone1 | ... | phone5 |
----------------------------------------------------------------------------------

共有2个表和2个连接.

我没有的粉丝data1,data2,data3因为它字段可以是一个巨大的痛苦.那么,你的意见是什么.

对于一个特定的名字,我想要获取居住在这个人居住的三个或更多城市的其他名字.