我有两张桌子:
DB_ACCEPTED_USERS:
+-------+-----------------+---------+
| id | photo_id | user |
+-------+-----------------+---------+
| 1 | 1234 | foo1 |
| 2 | 5678 | foo2 |
+-------+-----------------+---------+
DB_REJECTED_USERS:
+-------+-----------------+---------+-----------+
| id | photo_id | user | reason |
+-------+-----------------+---------+-----------+
| 1 | 4321 | foo3 | too fat |
| 2 | 8765 | foo4 | too thin |
+-------+-----------------+---------+-----------+
DB_ACCEPTED_USERS
是唯一活着的人。目前每秒都有数百个查询。只有管理员才能访问DB_REJECTED_USERS
。
我正在考虑将结构更改为:
DB_USERS:
+-------+-----------------+---------+---------+-----------+
| id | photo_id | user |rejected | reason |
+-------+-----------------+---------+---------+-----------+
| 1 | 1234 | foo1 | 0 | null |
| 2 | 5678 | foo2 | 0 | null |
| 3 | 4321 | foo3 | 1 | too fat |
| 4 | 8765 | foo4 | 1 | too thin |
+-------+-----------------+---------+---------+-----------+
这会对查询时间或性能产生影响吗?只有一个表是很好的,但它也会有很多数据在网上查询从不。在线只需要photo_id
和user
。
就性能而言,保留2个表对DB_ACCEPTED_USERS
的查询是否比只有1个表更好?
答案 0 :(得分:1)
可能不值得合并,因为很少使用拒绝。组合会稍微减慢您的查询速度,具体取决于它处理的额外数据量可能会很多。此外,您还必须在查询中添加一个测试,以便不包括被拒绝的用户,这也会为查询添加一些微秒。
答案 1 :(得分:1)
首先:你有性能问题吗?如果没有,为什么要改变?它现在有效吗?
如果您遇到性能问题?调查您的问题并找出原因,然后确定原因。
但是,我不知道你的其他表和它们之间的关系,但这两个表看起来都是同一种数据,因此它们属于同一个表。 不要担心性能问题,如果你的db-schema没问题,你可以在表中有数百万行,但没有注意到它。
答案 2 :(得分:0)
拥有多个null
值并不是一件好事。我相信你应该为用户使用一个表,为理由使用另一个表。通过这种方式,我相信查询数据库应该更容易。 db越多,标准化就越好。在您的第一种方法中,很难让用户与众不同。我的意思是如果另一个人获得foo3昵称并被接受。在我看来,下面的查询应该更好,但速度我不知道。
DB_USERS:
+-------+-----------------+---------+
| id | photo_id | user |
+-------+-----------------+---------+
| 1 | 1234 | foo1 |
| 2 | 5678 | foo2 |
+-------+-----------------+---------+
DB_REJECT_REASONS:
+-------+------------+---------+
| id | user_id | reason |
+-------+------------+---------+
| 1 | 2 |too fat |
| 2 | 4 |too thin |
+-------+------------+---------+