小编Mum*_*lic的帖子

我想使用GUID(uuid)来命名一个巨大的文件存储中的文件夹.每个存储项都有自己的文件夹和guid.最简单的方法是"x:\ items\uuid\{uuid} ..."
示例:"x:\ items\uuid\F3B16318-4236-4E45-92B3-3C2C3F31D44F ......"

我在这看到一个问题.如果您希望获得至少10,000件物品,可能会有100,000件甚至100万件以上,那该怎么办？我不想把这么多项目(子文件夹)放在一个文件夹中.

我想通过拆分guid来解决这个问题.取2个第一个字符在第一级创建子文件夹,然后取下两个字符,并创建子文件夹.上面的例子是 - >"x:\ items\uuid\F3\B1\6318-4236-4E45-92B3-3C2C3F31D44F ......"

如果guid的前4个字符实际上和预期的一样随机,那么我会在256个文件夹中找到256个文件夹,并且我总是在每个文件夹中找到合理数量的项目例如,如果你有100万个项目那么你得到 - > 1 000 000/256/256 =每个文件夹15.25项

在过去,我已经测试了第一个字符的随机性.(通过vb.net应用程序).结果:传播的项目均匀地退出文件夹.其他人也得出了同样的结论.看看在.NET中创建的Guid的前四个字节是如何均匀分布的？

我想到的可能分裂(例如100万个项目)C1 = GUID的字符1,C2 =字符2等

• C1\C2 \其他GUID - > 16*16*3906(差不多4000还是很多文件夹)
• C1\C2\C3\C4\Guid的其余部分 - > 16*16*16*16*15(不必要的文件夹分割)
• C1C2\C3C4\Guid的其余部分 - > 256*256*15(对我来说是最好的选择吗？)
• C1C2C3\Guid的其余部分 - > 4096*244(第一级的许多文件夹??)
• C1C2C3C4\Guid的其余部分 - > 65536*15(第一级的许多文件夹!)

我的问题是:

• 有没有人看到这种实现的缺点.(计划:*C1C2\C3C4\Guid的其余部分)
• 是否存在拆分Guids的一些标准,或者这样做的一般方法.
• 如果你在一个文件夹中放置几十万个子文件夹会发生什么(如果可能,我仍然不想使用任何拆分)

谢谢,Mumblic

UWP基础结构似乎具有便携式模型所需的一切。

• 操作系统与应用程序之间的清晰区分
• 明确区分不同的应用程序
• 更少的依赖
• 支持可移植类库

据我所知，目前不支持可移植方案。是UWP / WinRT的架构，还是我们将来可以期待的？

创建某种可以运行任何本地UWP应用程序的主机可执行文件有多困难。目前，我正在寻找不同Windows 10 PC之间的可移植性。跨设备或跨OS不需要太多。

我知道您可以侧面加载UWP应用，但这不是我想要的。