做这个工作近3年了，除了睡眠不足，另一个令我烦恼的就是每天在打交道的关系数据库。确切的说，这根本不是我想要的数据存储的解决方案。
看一下，同行发来的数据库，结构吓一跳，不大的一个项目近100张表，关系就是密密麻麻的连线，打印出来更是颇为壮观。
他们非常认真地按照书上说的1NF 2NF 3NF 来做，恩，这些表似乎是一张都省不了。真要使用起来这些数据就更困难了select join join join where and where and where group by....
insert table A and then update table B and then update table C....
受不了了。
有没有想过按照范式来设计的数据库，其优点是什么呢？
我想，主要的优点应该在于很容易，很灵活地对数据库里的数据作出各式各样的统计，排序。
但是，我的系统通常只是需要存储数据，读出数据。统计，排序并不是一个常用的功能。
说一下我想要的数据库结构吧：
比起操作二维表，我更喜欢操作文件目录，这是人类能够直观理解的数据存储形式，我想在程序里边使用这样的命令:
ls mk md cp mv ln ....
举例来说，我做的购物车系统。做出文件目录形式，会是这样的。绿色是目录，红色是数据体。
├---1：[Category]
│ ├---1：[Bag]
│ │ ├(1)Dinor Gdshoes.product.lnk
│ │ ├(2)Nice PoPo.product.lnk
│ ├---2：[Shoes]
│ │ ├(1)Nina Shoes.product.lnk
├---2：[Customer]
│ ├---1：[dino@yahoo.de]
│ │ ├---1：[Cart]
│ │ │ ├(1)Dinor Gdshoes.product
│ │ │ ├(2)Nice PoPo.product
│ │ ├(1)infomation
│ │ ├---2：[Order]
│ │ │ ├---1：[OSD-2007-09-11]
│ │ │ ├---2：[OSD-2007-09-13]
│ │ │ │ ├(1)infomation
│ │ │ │ ├---1：[Item]
│ │ │ │ │ ├(1)Nice PoPo.product
├---3：[Feedback]
│ ├(1)2008-07-19 0922.feedback
├---4：[Image]
├(1)infomation
├---5：[Inventroy]
│ ├(1)1451.Dinor Gdshoes
│ ├(2)7612.Nice PoPo
│ ├(3)7631.Nina Shoes
├---6：[Item]
│ ├(1)1451.Dinor Gdshoes
│ ├(2)7612.Nice PoPo
│ ├(3)7631.Nina Shoes
├---7：[Order]
需要新增用户，只需要在Customer目录下新增一个以客户email命名的目录。每个Customer目录下都有一个Cart目录和一个Order目录。客户购物的时候，程序里边就是两个命令 cd /Customer/dino@yahoo.de
cp Item/1451.Dinor ./Cart
当客户付款后生产订单时，只要
mv Cart/* Order/OSD-2009-02-24/
...
这样，多美妙。
另外，我还不打算把放弃数据库，存储而用文件系统存储这些。用普通的文件系统，它创造出来的问题估计是比解决的问题更多。
我想应该搞一个项目，专门用来定义 ls mk md cp mv ln 这样的命令接口。
资源管理器，接上项目，就能像是浏览目录一样。
（当然，我智力有限，项目的目录设计器一定是要有图形界面的操作，项目的编译器还要对可能的出错提醒。）
至于最终存储数据的位置，可以映射在简单的二维表数据库，文件系统，memcache，amazon的云，等等，考虑效率，混合使用。
......
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
