我需要在文件服务器上存储SQLite数据库中包含的大量数据。 我有机会将数据分成许多文件。 这意味着大部分数据被破坏的风险较小，移动更容易。 lesslocking等问题。我的问题是，有多less文件是太多的文件。 100.000？ 1.000.000？ 10.000.000个文件？ 换句话说，在文件服务器上创build文件的开销是多less？ 当我谈论开销时，我正在讨论创build文件的轮转次数。 我知道块和块大小，我不关心存储在许多文件浪费的存储空间。
我的问题不在于是否最好将这样的数据库存储在文件服务器上，而不是利用其他数据库软件的正确的数据库服务器。
该环境是一个微软的环境，但我不知道什么具体的文件服务器。
SQLite是一个非常酷的产品 – 但是如果你通过networking访问数据库，那么使用基于文件的访问来实现这一点是一个非常糟糕的主意 – 即使DB是只读的，并且你没有任何并发担心，performance将是可怕的。 你必须有一个很好的理由这样做。
在实践中，假设性能，并发性和locking不是问题，我不希望创build1000个文件或将相同的数据作为批处理写入10个文件之间有任何显着差异，但是这取决于底层文件系统的性质。 OTOH，在文件中随机发生大量的事务，我希望文件的数量越less效率越高。 对于阅读，我希望有一个类似的模式。 但只有一种方法可以确定 – 尝试一下。
在一个文件夹中超过10,000会给你带来资源pipe理器访问麻烦。 这可以通过将其分解成文件夹树来避免。
另外，如果您的文件不是群集大小的倍数（通常是4KB），那么它们将浪费每个文件的剩余部分。 取决于文件大小，这可能是重要的或不重要的。
由于开销，许多小文件的访问速度也很慢。 这可能会限制备份等事情的速度。 如果你可以devise你的使用顺序阅读更大的文件，并在内存中随机访问，你会更好。