v***s
发帖数: 1893 | 1 设计了一个数据库，发现一个表格很长很瘦，有可能超过200，000行，只有三四列。
从performance角度，是不是要重新设计？因为这种设计简单，容易写query。
如果重新设计新的，query会很复杂很头疼？
真不知道怎么取舍。请高手指点迷津。 |
w*******e
发帖数: 1622 | 2 就这点info, 估计没人能回答
【在 v***s 的大作中提到】
: 设计了一个数据库，发现一个表格很长很瘦，有可能超过200，000行，只有三四列。
: 从performance角度，是不是要重新设计？因为这种设计简单，容易写query。
: 如果重新设计新的，query会很复杂很头疼？
: 真不知道怎么取舍。请高手指点迷津。
|
v***s
发帖数: 1893 | 3 举个例子
table1 userid infomation
userID (PK)
...
table2 order information
orderID (PK)
userID (FK)
....
table3 order detail
OrderDetailID (PK)
orderID (FK)
goodsID (FK)
....
一个人可以有N个orders， 一个order可以有N个商品。
这样三层搞下来table3就是个有很多很多的行大表格。如果是amazon这样的网站，几亿
行都在一个大表格内，query怎么办？
是从数据库设计方面去优化，还是从数据库软件和硬件方面去考虑？
【在 w*******e 的大作中提到】
: 就这点info, 估计没人能回答
|
t*****g
发帖数: 1275 | 4 大点网站的search有几个是直接作database query的？
table太大变宽没什么意义，partition吧。
【在 v***s 的大作中提到】
: 举个例子
: table1 userid infomation
: userID (PK)
: ...
: table2 order information
: orderID (PK)
: userID (FK)
: ....
: table3 order detail
: OrderDetailID (PK)
|
v***s
发帖数: 1893 | 5 en，想到了partition，就是不够flexible。
【在 t*****g 的大作中提到】
: 大点网站的search有几个是直接作database query的？
: table太大变宽没什么意义，partition吧。
|
t*****g
发帖数: 1275 | 6 最简单的按PK mod作partition。
【在 v***s 的大作中提到】
: en，想到了partition，就是不够flexible。
|
v***s
发帖数: 1893 | 7 wow， good， tkx
how to expand linearly， not polynomially or exponentially in the future？
【在 t*****g 的大作中提到】
: 最简单的按PK mod作partition。
|
v***s
发帖数: 1893 | 8 never mind, I think I got it now. |
x***e
发帖数: 2449 | 9 for a production box, 200K there is no need at all for partition.
not even for 200M.
for more than 2B, you might need to start thinking about it.
【在 v***s 的大作中提到】
: never mind, I think I got it now.
|
