我有一个应用程序，在初始数据导入完成后将有大约25,000条记录。这些记录将各有1-3个相关的“文件附件”（.doc，.pdf等）。谁能给我关于如何实现这个功能的建议？具体来说，您将在哪里存储文件以及如何组织它们？
我不愿意将它们直接存储在数据库中，因为这会导致庞大的数据库。这看起来像是一个有效的问题吗？如果是这样，我认为我不希望在一个文件夹中看到多达100,000个文件。
答案 0 :(得分：3)
如果您可以使用SQL Server 2008，则它具有“FILESTREAM”功能。您可以将列定义为FILESTREAM类型，它将文件存储在文件系统上（可能在NAS设备上）。然后，您可以自己读取数据以传递给调用者，或者给调用者提供文件的文件系统路径，让他们读取它。
答案 1 :(得分：1)
将它们存储在文件系统上。 （我可以用相同的建议指向数百个pf帖子，根据经验，即使文件很小，你也可以从长远来看更好。）
设置Web应用程序具有读/写访问权限的文件夹，并创建一个页面，允许用户以任何合理的逻辑结构上传到此文件夹。
对于db结构，我会有一个单独的表用于文件attachmens，其中一个外键指向它们所关联的主记录。
答案 2 :(得分：0)
有一群人对在数据库中存储文件的注释感到不满。如果你是其中一个人，你可以采取类似于下面的方法。
创建一个存储与记录关联的所有文件的表。对于每个文件，创建一个唯一键（我使用GUID）以及其他文件元数据（文件名，大小，位置，用户，日期等）存储在该表中。将文件存储在服务器上。
这使您可以快速查询文件来源，并允许您根据需要移动存储库。
答案 3 :(得分：0)
我会根据你之后想要做的事情做出决定。
尺寸并不是真正的问题，也不是重要的。 NTFS最大输出为2 ^ 32个文件条目，因此100k不会让它出汗。并且SQL开销对于200GB的数据几乎没有增加，因此空间不太可能成为决定因素。
与我们始终存在的相同论点是否应该存储在数据库中（锁定，可索引/可查询属性，ACID，数据库安全性，已知备份/恢复等）与文件系统相比（更简单，更小，众所周知） ，可以轻松转移到外部存储，等等。）将成为决定因素。