c*********e
发帖数: 16335 | 1 如果table的每行数据是以二叉树结构存在硬盘里，那么我删去一行数据之后，这行的
primary key对应的数据是空的。比如现在有1００行数据在一个表里，我删去了
primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
keyid应该是5，而不是101,对不对？
但是，在使用mysql之类数据库的时候，现在有1００行数据在一个表里，我删去了
primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
keyid是101。 这说明数据不是按照二叉树存储在硬盘里的。
到底怎么回事呢？mysql, oracle,sql server,每个数据库软件不一样？ |
e****7
发帖数: 4387 | 2 这个primary key 是不是identity column? 所以才自己递增。 |
n******1
发帖数: 3756 | 3 mysql 有key id ?
【在 c*********e 的大作中提到】
: 如果table的每行数据是以二叉树结构存在硬盘里，那么我删去一行数据之后，这行的
: primary key对应的数据是空的。比如现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid应该是5，而不是101,对不对？
: 但是，在使用mysql之类数据库的时候，现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid是101。 这说明数据不是按照二叉树存储在硬盘里的。
: 到底怎么回事呢？mysql, oracle,sql server,每个数据库软件不一样？
|
e****7
发帖数: 4387 | 4
嗯，多半这个primary key column 加了auto_increment
【在 n******1 的大作中提到】
: mysql 有key id ?
|
s**********o
发帖数: 14359 | 5 TABLE硬盘存储不是B-TREE么，什么时候变BINARY TREE了？
LOGICAL存储和PHYSICAL存储不是一回事好不好，怎么硬盘
存储当然是不同的软件不同的操作系统是不同的。LZ明显
地基本功不扎实，很多概念都不懂，你的PK是个AUTO INCREMENT的
INDENTITY吧，否则怎么会只增不减，学得什么呀。 |
c*****d
发帖数: 6045 | 6 clustered table是b-tree结构
heap table不是
另外你这个问题根本和b-tree一点关系没有，就是这个字段有一个auto increment
【在 c*********e 的大作中提到】
: 如果table的每行数据是以二叉树结构存在硬盘里，那么我删去一行数据之后，这行的
: primary key对应的数据是空的。比如现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid应该是5，而不是101,对不对？
: 但是，在使用mysql之类数据库的时候，现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid是101。 这说明数据不是按照二叉树存储在硬盘里的。
: 到底怎么回事呢？mysql, oracle,sql server,每个数据库软件不一样？
|
f**d
发帖数: 1952 | 7 刚开始学数据库，试者回答一下，错的话，请改正。
PK很多是auto-number。PK本身一般是不能删除的，因为很多时候PK是另一个表的FK。
当增加一行新数据时，就会相应地分配一个新的PK值，否则，会发生在其它表（FK表）
中数据的不对应（不一致，混乱）。
至于表上的数据是如果存在硬盘上的，这个好象不在数据库考虑的范围里。
【在 c*********e 的大作中提到】
: 如果table的每行数据是以二叉树结构存在硬盘里，那么我删去一行数据之后，这行的
: primary key对应的数据是空的。比如现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid应该是5，而不是101,对不对？
: 但是，在使用mysql之类数据库的时候，现在有1００行数据在一个表里，我删去了
: primary key是keyid=5的那一行数据，那么我再加新的一行数据进这个表，新的数据的
: keyid是101。 这说明数据不是按照二叉树存储在硬盘里的。
: 到底怎么回事呢？mysql, oracle,sql server,每个数据库软件不一样？
|
c*****d
发帖数: 6045 | 8 PK是可以删除的，但是确实要保证没有FK指向这个PK的值
或者是你保证，或者是数据库保证
比如，employee和department表
employee(employee_id, dept_id)
1, A
2, A
3, B
4, B
department (dept_id)
A
B
C
department中的dept_id是PK，你删除C没问题，删除A部门要么你自己先删除employee
中A部门的员工，要么用cascade constraints自动删除
【在 f**d 的大作中提到】
: 刚开始学数据库，试者回答一下，错的话，请改正。
: PK很多是auto-number。PK本身一般是不能删除的，因为很多时候PK是另一个表的FK。
: 当增加一行新数据时，就会相应地分配一个新的PK值，否则，会发生在其它表（FK表）
: 中数据的不对应（不一致，混乱）。
: 至于表上的数据是如果存在硬盘上的，这个好象不在数据库考虑的范围里。
|
c*********e
发帖数: 16335 | 9 okay,就你这个可能和我的问题有点沾边。接着你的这个帖子问，
department (dept_id)
dept_id＝1， A
dept_id＝2， B
dept_id＝3， C
dept_id＝4， D
删除了department里面的C行之后，如果我想加一行新数据到department里面，让这行
新数据的dept_id=3,而不是dept_id＝5，可以吗？
PK是可以删除的，但是确实要保证没有FK指向这个PK的值
或者是你保证，或者是数据库保证
比如，employee和department表
employee(employee_id, dept_id)
1, A
2, A
3, B
4, B
department (dept_id)
A
B
C
D
department中的dept_id是PK，你删除C没问题，删除A部门要么你自己先删除employee
中A部门的员工，要么用cascade constraints自动删除
【在 c*****d 的大作中提到】
: PK是可以删除的，但是确实要保证没有FK指向这个PK的值
: 或者是你保证，或者是数据库保证
: 比如，employee和department表
: employee(employee_id, dept_id)
: 1, A
: 2, A
: 3, B
: 4, B
: department (dept_id)
: A
|
c*****d
发帖数: 6045 | 10 这要看你这个字段是怎么定义的
如果是auto increment，不行，只能是5
如果是个普通的字段，可以
【在 c*********e 的大作中提到】
: okay,就你这个可能和我的问题有点沾边。接着你的这个帖子问，
: department (dept_id)
: dept_id＝1， A
: dept_id＝2， B
: dept_id＝3， C
: dept_id＝4， D
: 删除了department里面的C行之后，如果我想加一行新数据到department里面，让这行
: 新数据的dept_id=3,而不是dept_id＝5，可以吗？
:
: PK是可以删除的，但是确实要保证没有FK指向这个PK的值
|
y*****g
发帖数: 677 | 11 我觉得你们所有的人都没有正确回答提问者的问题。
每行数据在硬盘里的存储相当复杂，很少人真正去研究它，而且也没有太多的必要。
MySQL 和其他的数据库实施的方法不一样。也INNODB ENGINE 为例，缺省的PAGE SIZE
是16K,它 有向前和向后的指针，指向其他的INDEX NODE, 数据就存在这个INDEX PAGE
里， 如果这个是LEAF NODE 的话。
未完待续 |
n******1
发帖数: 3756 | 12 说实在，他的问题并不准确，包括他补充的问题
其实Database System Concepts 这本书里面也提到很多存储的细节，当然针对每个数
据库的实现情况都不大一样
SIZE
PAGE
【在 y*****g 的大作中提到】
: 我觉得你们所有的人都没有正确回答提问者的问题。
: 每行数据在硬盘里的存储相当复杂，很少人真正去研究它，而且也没有太多的必要。
: MySQL 和其他的数据库实施的方法不一样。也INNODB ENGINE 为例，缺省的PAGE SIZE
: 是16K,它 有向前和向后的指针，指向其他的INDEX NODE, 数据就存在这个INDEX PAGE
: 里， 如果这个是LEAF NODE 的话。
: 未完待续
|
