n********6
发帖数: 1511 | 1 Survey family and the members
family (id, familyid, familymemberid, familyaddress, ...)
social scientists argue to set familyid and familymemberid in int format because they like keep most variable numeric (e.g. weighting.)
DBAs argue to have familyid and familymemberid in varchar format because there it does not make any sense to do calculation on familyid and familymemberid.
What do you think about this?
Street Smart Answer:
Listen to the Boss. If the Boss is a social scientist, do the numeric. If
the Boss is the CTO/CIO/VP of Tech, do the varchar.:) |
B*****g
发帖数: 34098 | 2 你这个是原创吗？
does
【在 n********6 的大作中提到】
: Survey family and the members
: family (id, familyid, familymemberid, familyaddress, ...)
: social scientists argue to set familyid and familymemberid in int format because they like keep most variable numeric (e.g. weighting.)
: DBAs argue to have familyid and familymemberid in varchar format because there it does not make any sense to do calculation on familyid and familymemberid.
: What do you think about this?
: Street Smart Answer:
: Listen to the Boss. If the Boss is a social scientist, do the numeric. If
: the Boss is the CTO/CIO/VP of Tech, do the varchar.:)
|
n********6
发帖数: 1511 | 3 原创！
身边发生的事情。
小事反应大道理。
和数据库有关。
给包子？
【在 B*****g 的大作中提到】
: 你这个是原创吗？
:
: does
|
B*****g
发帖数: 34098 | 4 不做calc ID就不能是number？
【在 n********6 的大作中提到】
: 原创！
: 身边发生的事情。
: 小事反应大道理。
: 和数据库有关。
: 给包子？
|
i****a
发帖数: 36252 | 5 int is better for performance.
because they like keep most variable numeric (e.g. weighting.)
there it does not make any sense to do calculation on familyid and
familymemberid.
【在 n********6 的大作中提到】
: Survey family and the members
: family (id, familyid, familymemberid, familyaddress, ...)
: social scientists argue to set familyid and familymemberid in int format because they like keep most variable numeric (e.g. weighting.)
: DBAs argue to have familyid and familymemberid in varchar format because there it does not make any sense to do calculation on familyid and familymemberid.
: What do you think about this?
: Street Smart Answer:
: Listen to the Boss. If the Boss is a social scientist, do the numeric. If
: the Boss is the CTO/CIO/VP of Tech, do the varchar.:)
|
p*********d
发帖数: 136 | 6 yes, number has better performance in this case for sorting and indexing |
b****t
发帖数: 112 | 7 Prefer int, more escalatable.
Don't really know your data, but suppose, you group people by state / county
, it's easier to say 1~10000 belongs to California, 10001~2000 belongs to ...
Flexible to do grouping, potential for other future marks, e.g. -100 as some
thing, performance cost probably no difference
because they like keep most variable numeric (e.g. weighting.)
there it does not make any sense to do calculation on familyid and
familymemberid.
【在 n********6 的大作中提到】
: Survey family and the members
: family (id, familyid, familymemberid, familyaddress, ...)
: social scientists argue to set familyid and familymemberid in int format because they like keep most variable numeric (e.g. weighting.)
: DBAs argue to have familyid and familymemberid in varchar format because there it does not make any sense to do calculation on familyid and familymemberid.
: What do you think about this?
: Street Smart Answer:
: Listen to the Boss. If the Boss is a social scientist, do the numeric. If
: the Boss is the CTO/CIO/VP of Tech, do the varchar.:)
|
n********6
发帖数: 1511 | 8 family is based on the random selection.
familyid is based on time serial.
if varchar, it would be easy for web development
county
...
some
【在 b****t 的大作中提到】
: Prefer int, more escalatable.
: Don't really know your data, but suppose, you group people by state / county
: , it's easier to say 1~10000 belongs to California, 10001~2000 belongs to ...
: Flexible to do grouping, potential for other future marks, e.g. -100 as some
: thing, performance cost probably no difference
:
: because they like keep most variable numeric (e.g. weighting.)
: there it does not make any sense to do calculation on familyid and
: familymemberid.
|
B*****g
发帖数: 34098 | 9 我小声说你们公司该换DBA了，闪。
to
【在 n********6 的大作中提到】
: family is based on the random selection.
: familyid is based on time serial.
: if varchar, it would be easy for web development
:
: county
: ...
: some
|
L*******r
发帖数: 8961 | 10 ＶＡＲＣＨＡＲ使用起来会方便一下，因为任何信息都可以储存。
如果将来你的公司接纳了其他的公司，你必须把这个公司的信息
存到你的数据库里，他们用的是ＶＡＲＣＨＡＲ，你就很方便。
ＩＮＴ理论上会有较好的ＰＥＲＦＯＲＭＡＮＣＥ，但实际中并
不明显。
另外ＩＤＥＮＴＩＴＹ只是在自动加１，但使用中会非常不方便。
ＩＤＥＮＴＩＴＹ不保证数字是连续的。如果一个ＩＮＳＥＲＴ
被ＲＯＬＬＢＡＣＫ，ＩＤＥＮＴＩＴＹ就不再连续。如果你有
ＲＥＰＬＩＣＡＴＩＯＮ，你需要自己修复一些数据，有
ＩＤＥＮＴＩＴＹ会非常麻烦。 |
|
|
B*****g
发帖数: 34098 | 11 不用ＩＤＥＮＴＩＴＹ怎么unique
【在 L*******r 的大作中提到】
: ＶＡＲＣＨＡＲ使用起来会方便一下，因为任何信息都可以储存。
: 如果将来你的公司接纳了其他的公司，你必须把这个公司的信息
: 存到你的数据库里，他们用的是ＶＡＲＣＨＡＲ，你就很方便。
: ＩＮＴ理论上会有较好的ＰＥＲＦＯＲＭＡＮＣＥ，但实际中并
: 不明显。
: 另外ＩＤＥＮＴＩＴＹ只是在自动加１，但使用中会非常不方便。
: ＩＤＥＮＴＩＴＹ不保证数字是连续的。如果一个ＩＮＳＥＲＴ
: 被ＲＯＬＬＢＡＣＫ，ＩＤＥＮＴＩＴＹ就不再连续。如果你有
: ＲＥＰＬＩＣＡＴＩＯＮ，你需要自己修复一些数据，有
: ＩＤＥＮＴＩＴＹ会非常麻烦。
|
g*****e
发帖数: 172 | 12 小声说,偶現在用的是varchar2.
【在 L*******r 的大作中提到】
: ＶＡＲＣＨＡＲ使用起来会方便一下，因为任何信息都可以储存。
: 如果将来你的公司接纳了其他的公司，你必须把这个公司的信息
: 存到你的数据库里，他们用的是ＶＡＲＣＨＡＲ，你就很方便。
: ＩＮＴ理论上会有较好的ＰＥＲＦＯＲＭＡＮＣＥ，但实际中并
: 不明显。
: 另外ＩＤＥＮＴＩＴＹ只是在自动加１，但使用中会非常不方便。
: ＩＤＥＮＴＩＴＹ不保证数字是连续的。如果一个ＩＮＳＥＲＴ
: 被ＲＯＬＬＢＡＣＫ，ＩＤＥＮＴＩＴＹ就不再连续。如果你有
: ＲＥＰＬＩＣＡＴＩＯＮ，你需要自己修复一些数据，有
: ＩＤＥＮＴＩＴＹ会非常麻烦。
|
L*******r
发帖数: 8961 | 13 你说呢？有多少种办法不用Identity也能保证Uniqueness？
【在 B*****g 的大作中提到】
: 不用ＩＤＥＮＴＩＴＹ怎么unique
|
B*****g
发帖数: 34098 | 14 量大了performance都不行
【在 L*******r 的大作中提到】
: 你说呢？有多少种办法不用Identity也能保证Uniqueness？
|
w*r
发帖数: 2421 | 15 performance performance performance
numeric based id is always the choice. ID should not carry info like state/
county, it is simple violation of normal form 1 .
use id as id, use state as state. do not mix your id with other info, if you
do that, go back to use IMS.VMS.ISPF.COBOL
numeric value as long as its range is big enough to hold data volume is
always the choice, regardless of RDBMS. all implementation of RDBMS uses
storage better on numeric value comparing to its offspring character types.
storage is cheap, IO is not.
end of discussion. |
L*******r
发帖数: 8961 | 16 理论上很正确。
you
.
【在 w*r 的大作中提到】
: performance performance performance
: numeric based id is always the choice. ID should not carry info like state/
: county, it is simple violation of normal form 1 .
: use id as id, use state as state. do not mix your id with other info, if you
: do that, go back to use IMS.VMS.ISPF.COBOL
: numeric value as long as its range is big enough to hold data volume is
: always the choice, regardless of RDBMS. all implementation of RDBMS uses
: storage better on numeric value comparing to its offspring character types.
: storage is cheap, IO is not.
: end of discussion.
|
i****a
发帖数: 36252 | 17 there are issue for lookup if you use varchar as ID
performance will be bad for large dataset, and you may run into lookup
errors
【在 L*******r 的大作中提到】
: ＶＡＲＣＨＡＲ使用起来会方便一下，因为任何信息都可以储存。
: 如果将来你的公司接纳了其他的公司，你必须把这个公司的信息
: 存到你的数据库里，他们用的是ＶＡＲＣＨＡＲ，你就很方便。
: ＩＮＴ理论上会有较好的ＰＥＲＦＯＲＭＡＮＣＥ，但实际中并
: 不明显。
: 另外ＩＤＥＮＴＩＴＹ只是在自动加１，但使用中会非常不方便。
: ＩＤＥＮＴＩＴＹ不保证数字是连续的。如果一个ＩＮＳＥＲＴ
: 被ＲＯＬＬＢＡＣＫ，ＩＤＥＮＴＩＴＹ就不再连续。如果你有
: ＲＥＰＬＩＣＡＴＩＯＮ，你需要自己修复一些数据，有
: ＩＤＥＮＴＩＴＹ会非常麻烦。
|
p*********d
发帖数: 136 | 18 今天早上起来看，这个上了头条了。 This is rare.
Keep hardworking, guys and gals. |
w*r
发帖数: 2421 | 19 大头，理论和实践上都证明了这是正确的，不要酸溜溜的
【在 L*******r 的大作中提到】
: 理论上很正确。
:
: you
: .
|
L*******r
发帖数: 8961 | 20 你在实践中看见区别了？你的数据量多大的时候看到的？
【在 w*r 的大作中提到】
: 大头，理论和实践上都证明了这是正确的，不要酸溜溜的
|
|
|
w*r
发帖数: 2421 | 21 the tables I deal with on daily basis regularily above 800M rows.
36 of them are 10s of billions.
3 of them are above 100B
【在 L*******r 的大作中提到】
: 你在实践中看见区别了？你的数据量多大的时候看到的？
|
L*******r
发帖数: 8961 | 22 是够大的。这么大的Table，应该很特殊了吧？干什么用的？
【在 w*r 的大作中提到】
: the tables I deal with on daily basis regularily above 800M rows.
: 36 of them are 10s of billions.
: 3 of them are above 100B
|
y****w
发帖数: 3747 | 23 DBAs argue to have familyid and familymemberid in varchar format because
there it does not make any sense to do calculation on familyid and
familymemberid |
