一个大的一个表,100列与很多小表

Ibr*_*nov 7 sql

我创建了一些网站,其中包含用户,评论,视频,照片,消息等.所有数据都在一个包含100列的表中.我认为一个表比更好,因为用户只需连接一个表但我听到了一些程序员不喜欢这种方法.有人能说我哪一个更好吗?一个非常大的桌子或很多小桌子.为什么我需要使用很多表?为什么它有用?哪一个对用户来说很快?大桌子和很多小桌子有什么优缺点?

Cat*_*lMF 11

在大多数情况下,单个表中的100列是糟糕的设计.

阅读本页:http://www.tutorialspoint.com/sql/sql-rdbms-concepts.htm

将您的数据分解为相关的块,并为每个块提供自己的表.

你说你有这些信息(用户,评论,视频,照片,消息)所以你应该有类似这些表的东西.

  1. 包含的用户(用户ID,姓名,电子邮件等)
  2. 包含的评论(评论ID,用户ID,评论文本等)
  3. 包含的视频(视频ID,用户ID,评论ID,视频数据等)
  4. 包含的照片(照片ID,用户ID,评论ID,照片数据等)
  5. 包含的消息(消息ID,用户ID,消息文本等)

然后,在编写SQL时,您可以根据所需的信息编写正确的SQL进行查询.

SELECT UserID, MessageID, MessageText
FROM Users as USR
    JOIN Messages as MSG
        on USR.UserID = MSG.UserID
WHERE USR.UserID = 1234567
Run Code Online (Sandbox Code Playgroud)

使用当前查询,您必须处理包含您不需要或不关心的数据的行.

编辑 只是为OP提供一些进一步的信息,说明为什么这是更好的设计.

让我们以"用户"为例.

在适当的数据库设计中,您将拥有一个名为Users的表,其中包含用户所需的所有必需列.用户名,电子邮件,身份证号等

现在我们要创建一个新用户,以便我们插入用户名,电子邮件和ID号.但是,等待我仍然需要填充97个其他列,其中包含与我们创建新用户的过程完全无关的信息!即使您在所有列中存储NULL,它也会在数据库中使用一些空间.

还想象一下,有数百名用户都试图从单个数据库表中进行选择,更新和删除.桌子被锁定的可能性很高.但是,如果您有一个用户更新Users表,另一个用户插入Messages表,则工作将展开.

正如其他用户所说,纯粹是表现.数据库需要获取所有信息并过滤掉您想要的内容.如果你有很多列,这是不必要的工作.

性能示例.

可以说你的数据库已运行多年了.您有5000个用户,2,000,000条评论,300,000张图片,1,000,000条消息.您的单个表现在包含3,305,000条记录.

现在,您要查找ID为12345且用户数超过20张的用户.您需要搜索所有3,305,000条记录才能获得此结果.

如果您有分割表设计,那么您只需要搜索305,000条记录.

性能明显提升!!

编辑2

性能测试.

我创建了一个包含200万行和1列的虚拟表.我运行了下面的查询,平均花了120多天执行了10次.

SELECT MyDate1 from dbo.DummyTable where MyDate1 BETWEEN '2015-02-15 16:59:00.000' and '2015-02-15 16:59:59.000'
Run Code Online (Sandbox Code Playgroud)

然后我截断了表并创建了6个列,并用200万行测试数据填充它们并运行相同的查询.10次​​执行平均耗时210毫秒.

因此,即使您没有查看额外数据,添加更多列也会降低性能.

  • 为什么有人需要在房子里有多个房间.为什么不只是一个非常大的房间?那会更简单..没有墙,没有门,容易吗?Oo问题是,"它取决于",在大多数情况下,你想要一个较小的事物分解(即房间或桌子)......在一些非常罕见/特殊情况下,你只需要一个大的"房间"(即健身房?) (4认同)
  • 表中有100列,有时甚至需要300列!它根本不是疯了,所以不要在这里误导人们.**在他的情况下**它是不必要的,可以分成多于1个表. (3认同)
  • @IbrahimHasanov 数据库不能那样工作。它们锁定表,而不是整个数据库。它们被设计为具有多个通过主键和外键连接的表。出于某种原因,它们被称为关系数据库管理系统 (RDBMS)。http://www.tutorialspoint.com/sql/sql-rdbms-concepts.htm 检查该页面的最后一部分并阅读它们“数据库规范化” (2认同)