Question

我们有2个表：FILES和FILEHISTORY定义如下：

FILES
( FILEID INT NOT NULL PRIMARY KEY,
 FILEBODY LOB,
 FILENAME VARCHAR)

FILEHISTORY
( FILEID INT NOT NULL PRIMARY KEY,
  FILENAME VARCHAR,
 some other fields)

也就是说，filehistory有扩展属性，说明用FILEID做了什么。

现在，我们的数据库伙伴在FILEHISTORY表上使FILEID为主，而在FILES表中使用FILEID将FILEHISTORY的FILEID作为外键。是对的吗？不应该是相反的吗？

Answer 1

Filehistory应该是：

FILEHISTORY
id int not null primary key
fileid int (foreign key to files)
other fields

filename可以从filehistory中删除，因为它已经在文件中可用，文件由fileid链接。

此模型允许一个FILES具有多个FILEHISTORY

Answer 2

如果按照数据库人员的建议进行此设计，它如何处理文件可以包含多个历史记录的事实？

例如：

文件A - 由您昨天创建

档案A - 今天由我改变

在这种情况下，基于以下架构： -

FILEHISTORY
( FILEID INT NOT NULL PRIMARY KEY,
  FILENAME VARCHAR,
 some other fields)

文件A的FileHistory中将有2条记录 - 比如FileID = 1且FileID = 2

问题 -

2个FileID中的哪一个（文件A的1/2）将存储在“FileID”字段中 “文件”表？
在这种设计中，使用ID将不再足以搜索文件的整个历史记录（也许这就是为什么FileHISTORY也有一个FileName字段，因为这是搜索整个历史记录的唯一真实方式文件 - 这不如搜索ID而不是字符串那样高效。
此外，文件是否可以重命名？如果上面的第2点有效，那么我想重命名文件将导致您丢失该文件的所有历史记录。

我在这里想说的是：

我认为您在FILES表中将fileID作为主要方法的方法是更好的方法。我认为它更真实地模拟了文件的实际关系。
根据系统的要求，建议的方法可能有效，但肯定需要更多的努力，并且在某些情况下可能会更昂贵/无法满足。

关于db设计的简单问题

2 个答案: