2

我有一个正在处理的项目,但我不知道哪个是“更好”的表关系模式。

相关区域的范围是:

  • 用户上传文件(成为所有者/作者)

  • 用户可以与其他用户共享文档(设置共享权限)

  • 任何有权访问文档的用户都可以签出文档(独占锁定)

我的原始架构如下所示:

替代文字

好处是:

  • 只有一个用户可以是作者。(授权)

  • 权限表仅包含“共享权限”(读、写)

  • 用户可以轻松区分他们“拥有”哪些文件(authorid)与共享文件(sharedfiles 表)。(这个是一个微弱的好处,我知道)

经过深思熟虑后,我认为这可能是一个更好的模式:

替代文字

好处是:

  • 所有文档关联都位于一个位置 (UserFiles)

  • 未来允许单个文档的多个作者/所有者的能力

权限表现在将具有读取、写入和所有者。一旦用户上传了文档,就会自动关联到新文档,并且用户将被授予“所有者”权限。

这使我得到了最终的架构:

替代文字

好处是:

  • 如果删除了用户文件关联(删除共享)并且该用户对该文件具有锁定(签出),则该排他锁定将被自动删除。

最后一个模型的唯一问题是我计划为每个部门添加“特殊”用户,以便用户可以将文档共享给整个部门。因此,我不确定是否要将共享关联与 checkoutID 相关联(如果有意义的话)。用户文件的查询看起来像“选择 userfiles.userid = me.userid || (userfiles.id == SpecialDepID && me.depid == SpecialDepID) 的所有文件”(主要伪代码)

自从我完成数据库模式以来已经有很长时间了,这个设计决定真的让我绞尽脑汁。哪个设计会“更好”真的让我很烦恼,更好的意思是更好的设计原则,根据以前的经验做出更好的决定,让设计更容易“成长”,等等。请让我知道你的想法!

最终解决方案

在 Michael Madsen 的帮助下,最终解决方案如下所示:

替代文字

UserFiles 上将有一个触发器用于删除,它将确定在删除关系时是否应该删除锁。

4

1 回答 1

1

如果只有这三个选项,我会选择第二个选项,并从 UserFiles 中删除触发器以处理您尝试使用第三种设计处理的问题。

您已经提供了选择第一个而不是第一个的充分理由,所以我不会重复。

然而,第三种设计并不好——查看文件是否被锁定并不简单。您必须查看是否存在 sharedFileID 文件ID 与您所追求的文件ID 匹配的位置,这意味着每个表有多个记录。您在 CheckedOutFiles 上缺少主键也不是一件好事,因此这也算在内。

但是,我们当然可以解决这些问题。如果您使用 FileID 作为 CheckedOutFiles 中的主键,您将能够避免这两个问题 - 您有一个有意义的主键,并且您可以轻松检查给定文件是否被锁定。

当然,即使你这样做了,你仍然有“特殊”用户的问题。一种简单的处理方法是将实际用户存储为结帐表的一部分 - sharedFileID 引用部门用户,而您仍然可以引用实际用户来验证您正在与正确的用户打交道.

通过这些更改,第三种设计似乎是最好的——您只为实际锁定的文件保留锁定信息的空间。

TL;DR:第三种设计,但使用 fileID 作为 CheckedOutFiles 中的 PK,并使用特定 UserID 作为 CheckedOutFiles 的一部分来处理“元”用户。

于 2010-10-10T18:06:38.473 回答