我有一个我正在研究的项目,我无法弄清楚哪个是“更好”的表关系模式。
该地区的范围是:
用户上传文件(成为所有者/作者)
用户可以与其他用户共享文档(设置共享权限)
任何有权访问文档的用户都可以签出文件(独家锁定)
我的原始架构如下所示:
好处是:
只有一位用户可以成为作者。 (AUTHORID)
权限表仅包含“sharerights”(读取,写入)
用户可以轻松区分他们“拥有”(authorid)和sharedfiles(sharedfiles表)的文件。 (这个是一个微弱的好处,我知道)
经过深思熟虑后,我认为这可能是一个更好的架构:
好处是:
所有文档关联都位于一个位置(UserFiles)
允许多个作者/单个文档所有者的未来能力
权限表现在具有读取,写入和所有者。用户上传文档后,将立即自动关联新文档,并为用户授予“所有者”权限。
这使我进入最终架构:
好处是:
最后一个模型的唯一问题是我计划为每个部门添加“特殊”用户,以便用户可以将文档共享给整个部门。所以我不确定是否要将共享关联与checkoutID相关联(如果这有意义)。对用户文件的查询看起来像“选择所有文件,其中userfiles.userid = me.userid ||(userfiles.id == SpecialDepID&& me.depid == SpecialDepID)”(主要伪代码)
自从我完成数据库模式以来已经有很长一段时间了,这个设计决定真的让我的大脑陷入困境。对于哪种设计会“更好”并且更好,我的意思是更好的设计原则,基于以往经验的更好决策,允许设计中更容易“增长”等等,这真的让我烦恼。请让我知道你的想法!
在Michael Madsen的帮助下,最终解决方案如下:
UserFiles上会有一个触发器用于删除,这将确定在删除关系时是否应删除锁。
答案 0 :(得分:1)
如果只有这三个选项,我会选择第二个选项并在UserFiles中删除触发器以处理您尝试使用第三个设计处理的问题。
你已经提供了很好的理由选择第一个,所以我不打算重复。
第三种设计并不好 - 看文件是否被锁定并不简单;你必须看看是否存在sharedFileID,其中fileID与你所追求的匹配,这意味着每个表有多个记录。你在CheckedOutFiles上错过了一个主键也不太好,所以这也违背了那个。
但是,我们当然可以解决这些问题。如果您使用FileID作为CheckedOutFiles中的主键,您将能够避免这两个问题 - 您有一个有意义的主键,并且您可以轻松检查给定文件是否被锁定。
当然,即使你这样做,你仍然有“特殊”用户的问题。您可以用来处理的一种简单方法是将实际用户存储为结帐表的一部分 - sharedFileID引用部门用户,同时您仍然可以引用实际用户来验证您是否正在与正确的用户打交道
通过这些更改,第三种设计看起来最好 - 您只为实际锁定的文件保留了锁定信息的空间。
TL; DR:第三种设计,但在CheckedOutFiles中使用fileID作为PK,并使用特定的UserID作为CheckedOutFiles的一部分来处理“meta”-users。