Генерация последовательных номеров в многопользовательском приложении saas

Как люди генерируют целые числа auto_incrementing для конкретного пользователя в типичном приложении saas?

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

Вдобавок ко всему, я мог бы сосчитать все счета пользователя, а затем добавить 1, но кто-нибудь знает какое-нибудь лучшее решение?

Ответы на вопрос(6)

Решение Вопроса

ипа

user_invoice_numbers (user_id int primary key clustered, last_id int)

и хранимая процедура или запрос SQL, как

update user_invoice_numbers set last_id = last_id + 1 where user_id = @user_id
select last_id from user_invoice_numbers where user_id = @user_id

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

Самое важное функциональное требование, которое вы должны проверить, этоwhether your system is allowed to have gaps in invoice numbering or not, Когда вы используете стандартный auto_increment, вы допускаете пропуски, потому что в большинстве известных мне баз данных при откате транзакции увеличенное число не будет откатываться. Имея это в виду, вы можете улучшить производительность, используя одно из следующих рекомендаций

1) Exclude the procedure that you use for getting new numbers from the long running transactions. Предположим, чтоinsert into invoice Процедура - это длительная транзакция со сложной серверной логикой. В этом случае вы сначала получаете новый идентификатор, а затем в отдельной транзакции вставляете новый счет. Если откат последней транзакции будет выполнен, авто-номер не уменьшится. Но user_invoice_numbers не будет заблокирован в течение длительного времени, поэтому многие пользователи одновременно могут вставлять счета-фактуры одновременно

2) Do not use a traditional transactional database to store the data with last id for each user. Когда вам нужно вести простой список ключей и значений, есть много небольших, но быстрых механизмов баз данных, которые могут сделать эту работу за вас.Список баз данных ключей / значений, НаверноеMemcached самый популярный В прошлом я видел проекты, где простые хранилища ключей / значений были реализованы с использованием реестра Windows или даже файловой системы. Существовал каталог, в котором каждое имя файла было ключом, а внутри каждого файла был последний идентификатор. И это грубое решение было все же лучше, чем использование таблицы SQL, потому что блокировки были выпущены и выпущены очень быстро и не были вовлечены в объем транзакции.

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

 09 июл. 2009 г., 22:10
memcached не является движком базы данных:code.google.com/p/memcached/wiki/…?
 Abhishiv Saxena09 июл. 2009 г., 22:07
Я не разрешаю редактировать / удалять счета, так что это немного упрощает все (без пропусков). Но сейчас я не беспокоюсь о производительности. Спасибо
 14 июл. 2009 г., 09:48
Если вы используете какую-либо технологию, которая может привести к пропускам (как видно из этого ответа, автоматическое увеличение будет), то вы можете уменьшить конкуренцию, разрешая предварительное получение фрагментов из последовательности. В худшем случае вы потеряете неиспользованный кусок.

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

 09 июл. 2009 г., 18:15
Да, хорошо аргументировано.
 09 июл. 2009 г., 17:51
Действительно ли атрибут идентификатора счета принадлежит объекту User? Это прагматическое решение, но не для пуристов!
 09 июл. 2009 г., 17:55
Если существует требование, чтобы номера счетов-фактур были последовательными для каждого пользователя, тогда "latestInvoiceNumberForThisUser" quot; похоже, тесно связан с пользователем.

ля / клиента, то создается впечатление, что они имеют «lastInvoice» Поле в каком-то постоянном хранилище (например, записи БД), связанном с пользователем, довольно неизбежно. Однако это может привести к некоторой конкуренции за «последний». число.

Действительно ли имеет значение, если мы отправляем пользователю счета 1, 2, 3 и 5 и никогда не отправляем им счета? 4? Если вы можете немного ослабить требование.

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

Обеспечение того, что числа являются последовательными, увеличивает сложность, добавляет ли это пользу для бизнеса?

 Abhishiv Saxena09 июл. 2009 г., 18:29
да, поскольку это приложения учета, числа должны быть автоматически увеличивать целые числа. Так что это тоже должно быть довольно солидно.

который должен удовлетворить ваши потребности (на несколько лет лучше, чем никогда!) :)

https://github.com/alisyed/sequenceid/

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

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

 21 дек. 2012 г., 12:21
В некоторых странах это не законные случайные числа. Должны быть последовательными для инспекции правительства.

Ваш ответ на вопрос