你这样设计无非是想存储一个树型结构。但是现在假如按照你的数据库模型，那么模型中描述该结构的就有了两个地方，一个是你上面所说的id的命名规则，一个就是preantid,那么你怎么在这两者之间达到一个维护同步，这个是一个比较麻烦的问题，如你将一个父节点下删除了一个节点，那么你的id是不是需要改变，如果需要改变那么便最好不要将该列作为主键(主键不要改变)，如果不变我想好象不是很合适。如要需求上有如查2.1下面的所有后代节点的需求，如果保存id列:可以用select * from project where id like '2.1.%'就可以实现。如果查询2.1的子节点,那么通过就不好查了，就必须有parentId的存在才好查。但是如果只有parentID这列，上面的那种查询又不好查了(当然可以，只是比较麻烦,得递归)。两者都保留有存在上面说的不好维护改变同步。 还有就是你可能是想2.1,2.1.1这种顺序显示，假如有id这一列，还得判定谁大谁小，这个也比较麻烦。 总结上面的所以我觉得应该不要你上面所说的id这一列，而增加一列如楼上说的自动生成主键列，还得在增加一列来维持节点的顺序，这个很好办，先添加的小，后添加的大，什么数据有这种规律呢，呵呵，“时间”，所以加这么一时间列，顺序编号使用代码生成，这个就简单了
还有就是你可能是想2.1,2.1.1这种顺序显示，假如有id这一列，还得判定谁大谁小，这个也比较麻烦。
总结上面的所以我觉得应该不要你上面所说的id这一列，而增加一列如楼上说的自动生成主键列，还得在增加一列来维持节点的顺序，这个很好办，先添加的小，后添加的大，什么数据有这种规律呢，呵呵，“时间”，所以加这么一时间列，顺序编号使用代码生成，这个就简单了