性能问题是保存文件的通用机制

时间:2017-09-16 18:22:20

标签: sql-server performance database-performance sql-server-performance

我想创建一个在我的应用程序和数据库中保存文件的通用机制,为此我想出了创建两个表schema的想法,以便保存与任何行相关的文件任何数据库表:

FileInfo
=================================================================
ID   FileName   ContentType   FileSize   DatabaseTableName  RowID

并创建具有OneToOne关系的下表以将文件数据保存在单独的表中,以便可以更快地执行查询FileInfo表:

FileData
=================================================================
ID  FileData

嗯,我不是数据库性能方面的专家,这就是为什么我想知道这样一个设计是否会在一个表中保存所有表的所有文件会导致性能问题,这是不是很糟糕练?

如果愿意的话,你能为我提供更好的解决方案吗?

提前致谢

1 个答案:

答案 0 :(得分:1)

我觉得如果没有一篇文章就无法回答这个问题。基本上可以将文件存储在数据库中。数据库和文件系统具有非常不同的属性。值得称道的是,您希望为您的框架用户提供选择适合他们案例的正确选择。

将其拆分为多个表(手动分区)或任何其他形式的分区都无济于事。 SQL Server没有处理极大表的固有问题。

数据库中的Blob会导致一些特定的缺点。这些斑点生活在哪里并不重要。

我喜欢将你分成两张桌子。通常,这不是必需的。如果正确编写了查询并且只提取了所需的列,则SQL Server根本不会触及未使用的blob列。

那就像你所说的那样分割大斑点通常很方便。 ORM不喜欢大行。工具(以及运行简单手册select *的管理员)现在可以查看FileInfo表,而不会因为数据量大而失败。

拆分不是必需的,但可以更轻松地使用数据库。