社区
研发管理
帖子详情
qingrun及各位高手:关系模型如何表达unix文件系统的结构关系?
l_cheng
2001-11-08 09:29:29
unix文件系统实际上是一个网状模型,一个文件可以被多个目录包含,而一个目录也可以属于多个目录,如果我想以关系模型表达,如何定义表和字段。并且检索时能有较好的效率
...全文
127
8
打赏
收藏
qingrun及各位高手:关系模型如何表达unix文件系统的结构关系?
unix文件系统实际上是一个网状模型,一个文件可以被多个目录包含,而一个目录也可以属于多个目录,如果我想以关系模型表达,如何定义表和字段。并且检索时能有较好的效率
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
8 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
l_cheng
2001-11-10
打赏
举报
回复
谢谢各位,我们将使用xml解决这个问题
jackyz
2001-11-08
打赏
举报
回复
我在其他项目中有做过类似的,这里把方案提出来,有更好方案的,请不吝赐教。
节点表,每一个条目都是一个“节点”
table iNode(
iNode_ID, --节点ID
iNode_Name, --名称
iNode_Type, --类型,比如:目录,文件等。
iNode__CreateDate, --创建时间
iNode__ModifyDate, --更新时间
... --其他
)
节点关系表,每一个“节点”都需要一个(或一个以上的)“父节点”
table iNode_Relation(
iNode_ID, --节点ID
iNode_PID, --父节点ID
... --其他
)
对两个表的操作严格应用“规则”,应该可以实现你的要求(树+链接)。
优点:能够实现高度复杂的层次结构,可以无级扩展。
缺点:对这样的结构进行检索需要进行“递归”,效率可能不高。如果用“数据cache”效率可以得到补救。
青润
2001-11-08
打赏
举报
回复
这个可能比较麻烦一些,我需要仔细想一想。
l_cheng
2001-11-08
打赏
举报
回复
实际上这个设计用网状结构表达最好,我可以用文件系统的原理实现,将管理信息放入文件中,将数据放入数据库;但现在要求用rdbms进行管理,既用数据库保存数据信息,也保存管理信息,但用关系结构来表达网状结构不仅复杂,而且效率低,仁兄可有好建议!
l_cheng
2001-11-08
打赏
举报
回复
是一个需要实现类似结构系统,由于保密的原因,不方便写出来,所以用文件系统的例子代替。
青润
2001-11-08
打赏
举报
回复
你是不是想按照unix的文件系统模型建立一个数据库结构能够实现这种效果?
SE1
2001-11-08
打赏
举报
回复
to(l_cheng):
这样改进一下是否更好?
节点表,每一个条目都是一个“节点”
table iNode(
iNode_ID, --节点ID,主键
iNode_Name, --名称
iNode_Type, --类型,比如:目录,文件等。
iNode__CreateDate, --创建时间
iNode__ModifyDate, --更新时间
... --其他
)
节点关系表,每一个“节点”都可与零个或多个“节点”发生关系
table iNode_Relation(
iNode_ID, --节点ID,主键,外键 -〉iNode_ID
iNode_OID, --其他节点ID,主键,外键 -〉iNode_ID
iNode_RelationType, -- iNode_ID与iNode_OID的关系,如“父”或“子”,可以定义其值域
)
两个表,两个外键!
l_cheng
2001-11-08
打赏
举报
回复
to(jackyz):
目前,我们的设计与你相同,但效率仍是问题。结构如下:
节点表,每一个条目都是一个“节点”
table iNode(
iNode_ID, --节点ID
iNode_Name, --名称
iNode_Type, --类型,比如:目录,文件等。
iNode__CreateDate, --创建时间
iNode__ModifyDate, --更新时间
... --其他
)
节点父关系表,每一个“节点”都需要零个或多个“父节点”,该表支持向上查找
table iNode_Relation(
iNode_ID, --节点ID
iNode_PID, --父节点ID
... --其他
)
节点子关系表,每一个“节点”都有零个或多个的“子节点”,该表支持向下查找
table iNode_Relation(
iNode_ID, --节点ID
iNode_CID, --子节点ID
... --其他
)
学习的状态和工作岗位的变化
关系
学习,在任何位置上都能学,相反,到了那个具体的位置上,反而不能学,因为岗位要求的是做,不是学.如果你是抱着学习的心态过去的,不会有人要你。本文2006年09月14日首次发于我个人的博客blog.csdn.net/
qingrun
,名字是:[软件人生]个人定位与岗位变更前的建议内容如下:工作一年了,想换个工作岗位,你应该如何做,如何考虑。下面是一段对话,大家可以随意看看,这个朋友的msn名字我修改了...
[企业管理]
qingrun
已经辞去软工/管理版块版主之位,今后主要在blog活动
因为论坛执行了所谓的一刀切的版主评价机制,然后,将评价结果对全体公布。 要知道管理,从来不可能一刀切,各个板块的状态,知识深度,影响程度和能够参与的人群层次都是有差异的。 硬性的切断,只能带来不公正的评价。 前天给csdn管理员发送了邮件,今天正式确定,
qingrun
已经不再担任软工/管理版块版主。特此公告。 感谢这九年来,软工/管理版块参与的各位弟兄给青润的支持和帮助! 论坛内辞职帖子...
『
qingrun
』[软件工程]SD2会中的简短体会
原文链接:http://blog.csdn.net/
qingrun
/archive/2007/12/10/1926888.aspx 作者:
qingrun
(青润心情) http://blog.csdn.net/
qingrun
本来早就想记录一下,看着太热了,我就不凑热闹了。一来二去,就拖延到了今天。SD2这次大会,感觉很不错,我看了几个专题:1、D语言程序设计的确是
高手
,可惜时间太短了,很多东西没说出来,或者说有意思的东西没说出来。2、Ivar的let‘s Do 有人会说,你写错了,Ivar写的是:let’s
概要设计,详细设计之间的
关系
是什么?
概要设计,详细设计之间的
关系
是什么?楼主lanying(蓝鹰)(问个不休)2004-08-12 19:22:06 在 软件工程/管理 / 管理版 提问我的看法: 概要设计只说明系统有多少个模块,各模块之间的接口和个模块本身的功能 详细设计说明某个具体模块如何实现,粒度应该比程序略高一些 但是问题来了,各个模块之间是有层次
关系
的,也有先后逻辑
关系
。这就说明,在概要
软件管理和软件开发文档的
关系
?(转自CSDN)
jiangtao: 观点1: 文档固然重要,但精细到什么程度就有待大家一起探讨了。目前大部分都是为了文档而文档就失去了意义。对于文档我更倾向于写个大概,具体细节开发的时候不断请教。如果要等到全部细节都写出来,工作量实在太大了。实际上也很少有光看文档就可以明白的,还是需要当事人讲解的。讲解容易,写出来就难了。这两种方式哪个成本更高,就不太好说了。 企业文化氛围是为了企业利益最大化而建立的。企业文化
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章