0

I'm currently in the process of designing a database. We have an existing system that was not designed very well and we are ironing out all of the small issues that are clearly visible, e.g. a varchar for a true/false flag instead of a bit.

What I want to know is, how do you know that you have got a sweet database design? Or is this a myth? I mean, the structure may look amazing on paper, but when some data is in there how will it perform.

Are tables that store "lookup" values faster than storing full descriptive text? e.g.

Error table

Id    ErrorId    DateCreated
1     1          09/12/2011
2     5          10/12/2011

Error Description table

Id    Description
1     Warning - failed to validate
2     Failed to locate file

In this scenario, would creating a view be more beneficial than writing the SQL including the necessary join?

Sorry if I have posted this question in the wrong place.

4

1 回答 1

0

存储“查找”值的表是否比存储完整的描述性文本更快？

我们在我工作的地方进行了测试。（有点。我们没有将查找表与任何其他类型的表区分开来。）但是让我指出，您的问题与查找表无关；而是与查找表有关。您的问题是关于代理键（身份证号）。您可以在不使用 ID 号的情况下创建“查找”表。

有关时间的示例，请参阅此 SO question。似乎有一个转折点。在临界点以下，基于自然键的查询通常比基于 id 号的查询运行得更快。（更窄的表和更少的连接。）但是在临界点之后，连接代理键比自然键运行得更快。

但“更快”并不一定意味着“快”。而“较慢”可能仍然足够快。

于 2011-12-14T10:22:05.640 回答