0

我很想对我目前追求的这个数据库设计是否合理提出一些意见。

假设我正在构建一个名为“Home”的表,该表有一个名为“rooms”的文本字段。在这个字段中是这所房子的一组房间的序列化数据。当然,我的第一直觉是将这些数据标准化为单独的“房间”表。然而,由于过去对过度规范化的数据库的一些令人沮丧的经历,我停下来问自己几个问题:

  1. 我需要找到一个特定的房间吗?
  2. 我是否需要更新单个房间?
  3. 任何家庭记录会共享房间记录吗?

每个问题的答案都是“不”。每个家庭的房间记录都是独一无二的。例如,永远不需要执行查询来找出数据库中有多少家有浴室。数据将始终从 Home 的角度提取。卧室和浴室的数量将明确存储在 Home 记录中以供搜索。

因此,我不必经常加入房间,而是想知道将这些数据序列化并将其弹出到文本字段中会有什么危害。

这对我来说很有意义,但我希望进行健全性检查。感谢您的任何意见!

4

4 回答 4

3

好吧,您今天可能不需要查询以找出以下内容:

  • 俄亥俄州一个家庭的平均浴室数量是多少?
  • 房子在哪里有更多的卧室?东海岸还是西海岸?
  • 房价与主卧室的大小有何关系?将主卧室面积增加 30% 的平均美元价值回报是多少?

等等等等

如果您从一开始就正确设计您的基础,那么您将来会处于一个更好的位置……无论现在的捷径看起来多么诱人。

另外,使用单独的 ROOMS 表,您将能够添加稍后有意义的其他房间字段(如宽度/高度、颜色、楼层等),如果数据只是被整合到一个单一的,这将非常困难场地。

人们会想以意想不到的方式查询,例如:

  • 我膝盖不好。你能列出一楼有主卧室和主浴室的房子吗?

通常,拥有 ROOMS 表只会使您的应用程序更强大,更易于使用。

嘿,我明白你所说的“过度规范化的数据”。我们都去过那里,它确实咬人。但是,在包含住房信息的数据库中拥有 ROOMS 表并没有被“过度规范化”。它只是以正确的方式构建应用程序。

于 2011-01-05T16:11:53.820 回答
3

一个务实的答案...

  • a)您将来可能想要分解它的概率
  • b) 现在不这样做的好处
  • c) 稍后更改模式的成本。

如果a * c > b那么你现在应该分解。

于 2011-01-05T16:17:25.850 回答
1

除了其他人所说的做正确的事情之外,我想添加关于性能的评论。

由于您将序列化的房间数据作为列存储在表 Home 中,因此行大小将显着增加。这将导致所有其他查询的性能变差

于 2011-01-05T16:40:39.060 回答
0

好吧,你说房间记录是唯一的,但你不能强制执行。因此,您无法在当前设计中确定这一点:您的所有代码都应该完美地表示这一点。

“不断加入”并不难做到,但如果是这样,你总是可以为此创建一个视图,你就完成了。

于 2011-01-05T16:08:32.417 回答