Как предоставить уникальный идентификатор в автономном режиме?

Question

В приложении учета клиент-сервер в форме счета-фактуры, когда пользователь сохраняет счет, он получает с сервера номер счета-фактуры, например 90134, и сохраняет счет-фактуру с этим номером.Номер счета необходим для клиента.Так что в автономном режиме (например, когда сеть отключена), как предоставить уникальный идентификатор?

Хорошо ли использовать String Id, как этот шаблон: клиент + инкрементный номер?

Я не хочуиспользовать GUID с.

Answer 1

Если вы заранее знаете, сколько номеров счетов-фактур вы сгенерируете для каждого клиента в течение автономного периода, сможете ли вы предварительно назначить номера счетов-фактур? например если каждый клиент может генерировать только 4 счета за автономный период, вы можете выделить блок из 4 номеров для каждого клиента. Это может включать в себя дополнительный столбец в вашей БД для хранения значения, указывающего, является ли номер уже созданным счетом, или предварительным распределением номера. В зависимости от структуры и ограничений в вашей БД, вам также может понадобиться сохранить некоторые фиктивные данные для обеспечения ссылочной целостности.

Недостатком может быть то, что ваш блок номеров может не использоваться последовательно или вообще не использоваться, поэтому номера ваших счетов-фактур будут не в хронологическом порядке. Кроме того, вы столкнетесь с проблемами при использовании пула доступных номеров.

Answer 2

Я полагаю, что номер счета (целое число) является инкрементным: в этом случае, поскольку у вас нет возможности узнать номер последнего счета, вы можете сохранить счет в локальной базе данных db / cache / xml без номера счета и дождатьсясетевое соединение для вставки новых записей в БД (тогда будет сгенерирован номер счета)

Answer 3

Вы можете использовать Guid:

var myUniqueID = Guid.NewID();

В SQL-сервере соответствующий тип uniqueidentifier.

Обычно Guid - это 128-битное число.

Подробнее о Guid вы можете прочитать:

http://en.wikipedia.org/wiki/Globally_unique_identifier

http://msdn.microsoft.com/en-us/library/system.guid.aspx

Answer 4

Вы можете начать свои номера для каждого клиента в другом диапазоне ... например ::

• клиент 1: 1 000 000
• клиент 2: 2 000 000
• клиент 3: 3 000 000

Обновляйте их время от времени, когда является соединением, чтобы избежать дублирования.
Это не на 100% пуленепробиваемый, но, по крайней мере, лучше, чем ничего.

Моим фаворитом для этого все равно будет GUID, поскольку они всегда уникальны.

Answer 5

похоже, что невозможно создать уникальные числа с двумя разными системами, которые работают автономно, когда они должны быть хронологическими и без пропущенных чисел.

imho нет никакого способа, если последний номер (на сервере) был 10, узнать, должен ли я вернуть 11 или 12; я должен был знать, если 11 уже использовался другим человеком.

Я могу только представить, чтобы использовать временный номер, а затем перенумеровать эти номера, но если счета распечатаны и номер не может быть изменен, я не знаю, как вы могли бы достичь такого решения.

Answer 6

Обходной путь есть, но это просто «грязный взлом», вам следует серьезно пересмотреть вопрос о принятии новых записей данных в автономном режиме, особенно когда речь идет об уникальных идентификаторах, которые нужно вставить во многие таблицы.

Скажите, что выу вас есть таблица "orders" и другая таблица "orderDetails" в вашем локальном наборе данных:

1 - добавьте tmpID типа integer в таблицу "orders", чтобы временно идентифицировать каждый уникальный заказ.

2- используйте tmpID вашего вновь созданного заказа в оставшейся части процесса (скажем, для добавления продуктов в текущий заказ в таблице orderDetails)

-> после подключения к серверу в одномДля транзакции выполните следующую команду:

1 - вставьте первый заказ в таблицу "orders"

2 - получите его уникальный идентификатор, сгенерированный на вашем сервере SQL

3 - найдите каждую строкув "orderDetails", который имеет tmpID currentOrder.tmpID и вставляет их в таблицу "orderDetails" на вашем сервере

4 - зафиксируйте транзакцию и перейдите к файлуollowing row.

Имейте в виду, что это очень плохое кодирование и что оно может стать очень грязным и трудным в обслуживании.