.net 中的自动递增 Id
我们需要将xml文件存储在文件系统中。 xml 文件应具有范围从（00000001 到 99999999）的 uniqueId 有没有办法自动增加生成的任何新 xml 的 id。 xml存储在文件夹结构中，结构很复杂。 我尝试计算 xml 文件的数量，这似乎是一个缓慢的操作。 该应用程序是用c#.net开发的 任何人都可以建议任何其他方式来保存数据。 数据库似乎是选项之一，但将值存储在只有一列的表中听起来不是一个好主意。 有人可以建议其他方法吗？
We need to store xml file in file system.
The xml files should have a uniqueId ranging from (00000001 to 99999999)
Is there a way to auto increment the ids for any new xml generated.
The xml are stored in folder structure which is complex.
I tried taking the count of xml files that this seems to be a slow operation.
The application is developed in c#.net
Can anyone suggest any other way of persisting the data.
Database seems to be one of the opetion but storing a value in a table with just one column doesn't sound like a great idea.
can anyone suggest other ways?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我假设您的应用程序没有状态，这意味着它将启动和停止多次。
我会考虑使用应用程序设置，该设置在标准 .NET 项目中是可供您使用的读/写选项。该值可以是强类型的，并将存储在应用程序配置文件中。
示例： http://msdn.microsoft.com/ en-us/library/aa730869%28VS.80%29.aspx
I am assuming your application is not stateful, meaning it will be started and stopped several times.
I would consider using an Application Setting which in a standard .NET project is an option available to you that is read/write. The value can be strongly typed and will be stored in the application configuration file.
Examples: http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx
如果您不想为此使用数据库，则可以将上次使用的 ID 存储在 应用程序配置设置。
If you don't want to use a database for this, you could just store the last used ID in your application configuration settings.
保留属性文件中最后使用的值，您可能已使用该值来保留您可能执行的许多其他初始设置。
Persist the last used value in a properties file that you might already be using to persist a lot of other initial settings you might do.
保留一个仅包含最近使用的号码的文件怎么样？
how about keeping a file with just the recently used number it it
将其存储在数据库中没有任何问题。它可以使用一张只有一条记录和一个（整数）字段的表。或者记录的其他字段可以用于应用程序的其他状态。 （如果将它与需要唯一键的东西一起使用，它可能有一个代理主键，它只有一个固定值，例如始终为 1。）
增加它可以通过读取然后写入该值并返回新值的事务来完成。 （这样如果同时调用，它将返回唯一的值。）
如果（且仅当）您已经拥有数据库，这可能会很方便。
对于 InterBase 或 FireBird，您可以使用 Generator（支持线程安全递增的标量值）。
或者，您可以将其存储在文件中。 （它可以位于同一目录中，命名为使其不会与其他输出文件之一冲突。）您可以打开文件进行写入、读取、用新值覆盖，然后关闭它。如果两个进程或线程尝试同时更新它，一个进程或线程将因锁定错误而失败，并且必须重试（从而获取下一个数字）。
可以使用任何其他存储值的方式来完成同样的操作，例如您的应用程序配置设置文件（如其他人所建议的那样）或 Windows 注册表（这样做的主要原因是，如果您希望它在可能安装在的程序之间共享）计算机上的不同位置，但输出文件目录中的文件也可以实现此目的）。但如果它可以同时调用，您必须确保您选择的任何机制都能处理这个问题。
如果您不想单独存储计数器，并且旧文件永远不会被删除，您可以使用一种优化的方法来测试最后一个文件是什么，例如测试是否存在数字为 1 的文件（使用padding），然后将该值加倍并再次测试，直到找到不存在的值，然后测试最后找到的值和最低的不存在值之间的值。然后重复选择剩余可能范围中间的那个，直到剩余范围为一个值。
它可能不会更快，具体取决于测试文件的存在性需要多长时间。如果不添加锁定机制，这不适用于并发访问（例如创建一个虚拟文件并保持其打开状态，同时执行此操作，然后删除它（并等待该文件是否存在并锁定写入））。
当然，如果创建文件的进程在每次文件创建之间继续运行，并且是唯一创建文件的进程，则您可以将计数器保存在内存中，并且只需在每次进程启动时重新建立该值。 （如果多个线程可以创建文件，则必须同步对计数器的访问。）
There's nothing wrong with storing it in a database. It could use a table with just one record, with one (integer) field. Or other fields of the record could be used for other state of the application. (If using it with something that expects a unique key, it could have a surrogate primary key, which would just have a fixed value, e.g. always 1.)
Incrementing it would be done with a transaction that reads then writes this value, and returns the new value. (So that it will return unique values if invoked concurrently.)
This is probably convenient if (and only if) you already have a database.
With InterBase or FireBird, you could use a Generator (a scalar value with support for thread-safe incrementing).
Alternatively, you could store it in a file. (It could be in the same directory, named so that it can't conflict with one of the other output files.) You would open the file for writing, read it, overwrite with the new value, and close it. If two processes or threads tried to update it at the same time, one would fail with a locking error, and have to retry (thus getting the next number).
The same can be done with any other way of storing a value, e.g. your application configuration settings file, as others have suggested, or the Windows Registry (the main reason for that would be if you want it to be shared between programs potentially installed in different places on the machine, but a file in the directory of the output files also achieves this). But if it can be invoked concurrently, you have to ensure that whatever mechanism you choose handles this.
If you don't want a separate storage of the counter, and old files are never deleted, you could possibly use an optimised way of testing what the last one is, for example test for the existence of a file with the number 1 (with padding), then double this value and test again, until you find one that doesn't exist, then test the value half way between the last found one and the lowest non-existent one. Then repeatedly choose the one in the middle of the remaining possible range, until the remaining range is one value.
It might be no faster, depending on how long testing existence of a file takes. And this doesn't work for concurrent access, without adding a locking mechanism (such as creating a dummy file and keeping it open, while doing this, then deleting it (and waiting if this file exists and is locked for writing)).
Of course, if the process creating the files continues running between each file creation, and is the only process creating them, you could hold the counter in memory, and only have to re-establish the value each time the process starts. (If multiple threads can create the files, you'd have to synchronize access to the counter.)