线性的地址空间 如何存储线性可变数据
这个问题一直困扰着我

我们知道 在操作系统中 文件的存储是线性的，那么如果我要设计一个单文件数据库的文件，要如何设计呢？


如果我们分配一个固定的大小给每一个类型结构 那么如果以后有如果我要修改这个结构中的某个存储的数据，那岂不是要修改整个结构的大小 
而如果这个结构是整个数据库文件中的其中一个 那岂不是我要移动修改结构之后的所有数据，那样的工作量未免也太大了吧？


为了更加能够说明问题
我画了一张图 便于大家理解
CSDN把图片压缩过了 品质变得很差，我也不知道 怎么解决 大家将就一下吧


大家一起讨论讨论

看这个问题有没有什么完美的解决方案

------解决方案--------------------
"操作系统"中存储文件?是在硬盘上存储吧?线性存储的话,可以采用链表的结构啊,不一定非要在物理结构上也保持连续吧?不知道您是要创建一种新的数据库呢,还是要创建分布式的文件存储系统.关注...
------解决方案--------------------

探讨

我们知道 在操作系统中 文件的存储是线性的，...

------解决方案--------------------
操作系统里面有介绍。

段式、分页式存储。
------解决方案--------------------
既然想“设计一个单文件数据库的文件”，为什么不参考别人的数据库存储管理？这个领域，学术上已经非常成熟，资料和文献也非常的丰富。

比如说微软SQL的页和区体系结构？
http://msdn.microsoft.com/zh-cn/library/cc280360.aspx
------解决方案--------------------

探讨

方案一：获取 磁盘扇区簇并且自己管理，在必要的时候修改簇指针

方案二：对数据文件进行预划分，然后使用索引值进行true/false 和文件分块指针集管理


方案二比较容易实现，但是并不是很节约空间。
方案一是最好的，但是技术上有难点，主要是 .net操作扇区可能比较困难，至少 似乎没有搜索到相关已有的实现...

------解决方案--------------------
有数据的磁盘块，例如一个1024为大小的块吧 --> 有数据的磁盘块，例如一个1024K为大小的块吧

例如说我们知道SQL Server的记录最大也不到8K（实际上比8K小几十个字节，显然磁盘块里边需要有管理信息），而Mongo则是16M。后者经过了仔细的测试，证明16M要比8K高效多了（当然也是因为管理方式不同）。

磁盘块里边当然可以有多条记录，而不是只能有一条。
------解决方案--------------------

探讨

根据进一步的搜索 查看 各项资料...
现在 知道 基本上 数据库 貌似 都是 固定块划归固定大小的。。。
就好像 我们 定义一个 新的表 都要输入 类型，大小（长度）等相关信息。。。。

恩，看来即使是 想Oracle这样的数据库 也没有什么更好的策略，尽管Oracle很成功。。。

当某区域 信息失效时会，被标识。以备后用...
而不是将后面的所有数据向后挪...

------解决方案--------------------

探讨

引用:

引用:

根据进一步的搜索 查看 各项资料...

看来你很难想象磁盘中的链表如何保存。

举个例子。比如说1024K为一个块...


16M=256*64KB
一个byte可以表示256个数字
操作系统内存粒度大小是64KB

我怀疑Mongo可能是为了
1.索引时长度更短时间更快……

------解决方案--------------------

探讨

我怀疑Mongo可能是为了
1.索引时长度更短时间更快
2.内存读取时按64KB为单位整块读取更加方便
3.16M是一个适中的数据
4.节约空间，256个内存块 这个数字多也不算多，少也不算少。
在建立索引时只需要一个字节即可标出数据块位置，