Лучший способ для генерации последовательных уникальных значений

Question

Лучший способ для генерации последовательных уникальных значений

0

Каков наилучший способ генерации последовательных значений при наличии балансированной нагрузки базы данных и экземпляров приложения?

Например, у меня есть база данных mysql, сбалансированная по нагрузке. Мое приложение PHP, развернуто с докером и имеет 3 контейнера

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

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

TRIGGER ON UPDATE - хорошее решение или нет?

Thnks для ваших ответов

pop_up 27 июль 2018, в 12:13

Источник

1

«Я должен создать уникальный номер счета в зависимости от того, с каким обществом это связано». Это плохое требование ИМО. Номер счета должен быть просто числом. Другие метаданные могут содержать информацию о том, к какому клиенту они относятся. И что вы подразумеваете под «испущенным» - вы имеете в виду, когда он отправляется клиенту? Почему вы должны ждать до тех пор, пока не создаст номер? Есть ли какая-то настоящая деловая причина для этого?
ADyson 27 июль 2018, в 09:44
0

Требование плохое, но это то, что хочет клиент, и он позволяет сортировать файлы. Счет может быть сгенерирован и не сразу утвержден, потому что пользователь может изменить его содержание. Когда счет подтвержден, он действителен и «эмитирован». На данный момент мне нужно сгенерировать свой идентификатор, потому что, если счет отменен и не выдан, у меня не должно быть дыры в моем списке сгенерированных идентификаторов.
pop_up 27 июль 2018, в 15:28
0

«но это то, чего хочет клиент», вам не обязательно делать все, что хочет клиент, если вы можете доказать им, что это не очень хорошая идея, и у вас есть лучшая идея, которая все еще позволит ему вести бизнес эффективно (может быть, даже более эффективно - например, без технических проблем!). Если вы изложите ясное и разумное обоснование, вы сможете получить соглашение или хотя бы компромисс. Они не ИТ-эксперт ... вы. Если есть технические трудности с требованием, которое существует в этом случае, вы должны сказать об этом.
ADyson 27 июль 2018, в 15:40
0

«У меня не должно быть дыры в моем списке сгенерированных идентификаторов» - кого это волнует? Это просто число. Это уникальный идентификатор записи, это его единственная работа. Не используйте его, например, для подсчета количества счетов для данного клиента или чего-то еще - для этого предназначен SQL COUNT (). Опять же, если ваш клиент просит об этом, просто осторожно объясните ему, почему вы не собираетесь делать это так, потому что это создает технические трудности и не нужно - есть другие способы передать информацию, которую пытается попытаться найти номер счета. представлять, и вы их предоставите.
ADyson 27 июль 2018, в 15:41
0

Кстати, я видел биллинговые системы, в которых счет изначально находится в состоянии «черновик» и имеет уникальный «идентификатор черновика», сгенерированный базой данных. Затем, когда он подтверждается и передается клиенту, создается строка в другой таблице с окончательными неизменяемыми данными, и ей присваивается окончательный «идентификатор счета», который снова генерируется базой данных. Затем проект и счет связаны между собой ключевыми отношениями в БД. Так что это один вариант для вас, чтобы обойти эту ситуацию. Опять же, это просто автоматически сгенерированное число, без лишних попыток создать бессмысленные искусственные последовательности и т. Д.
ADyson 27 июль 2018, в 15:46
0

«Вы не обязательно должны делать все, что хочет клиент, если вы можете доказать им, что это не очень хорошая идея»: здесь я просто пытаюсь выявить проблему, не объясняя все системы, существующие вокруг. Требование клиента хорошее. Есть электронное управление документами и другие приложения, работающие с моим приложением. И да, у меня не должно быть дыры в моем списке сгенерированных идентификаторов, потому что, по закону, это требование ( service-public.fr/professionnels-entreprises/vosdroits/F23208 ).
pop_up 30 июль 2018, в 08:18

Показать ещё 4 комментария

Теги:

php

mysql

2 ответа

Ещё вопросы

«Я должен создать уникальный номер счета в зависимости от того, с каким обществом это связано». Это плохое требование ИМО. Номер счета должен быть просто числом. Другие метаданные могут содержать информацию о том, к какому клиенту они относятся. И что вы подразумеваете под «испущенным» - вы имеете в виду, когда он отправляется клиенту? Почему вы должны ждать до тех пор, пока не создаст номер? Есть ли какая-то настоящая деловая причина для этого?
Требование плохое, но это то, что хочет клиент, и он позволяет сортировать файлы. Счет может быть сгенерирован и не сразу утвержден, потому что пользователь может изменить его содержание. Когда счет подтвержден, он действителен и «эмитирован». На данный момент мне нужно сгенерировать свой идентификатор, потому что, если счет отменен и не выдан, у меня не должно быть дыры в моем списке сгенерированных идентификаторов.
«но это то, чего хочет клиент», вам не обязательно делать все, что хочет клиент, если вы можете доказать им, что это не очень хорошая идея, и у вас есть лучшая идея, которая все еще позволит ему вести бизнес эффективно (может быть, даже более эффективно - например, без технических проблем!). Если вы изложите ясное и разумное обоснование, вы сможете получить соглашение или хотя бы компромисс. Они не ИТ-эксперт ... вы. Если есть технические трудности с требованием, которое существует в этом случае, вы должны сказать об этом.
«У меня не должно быть дыры в моем списке сгенерированных идентификаторов» - кого это волнует? Это просто число. Это уникальный идентификатор записи, это его единственная работа. Не используйте его, например, для подсчета количества счетов для данного клиента или чего-то еще - для этого предназначен SQL COUNT (). Опять же, если ваш клиент просит об этом, просто осторожно объясните ему, почему вы не собираетесь делать это так, потому что это создает технические трудности и не нужно - есть другие способы передать информацию, которую пытается попытаться найти номер счета. представлять, и вы их предоставите.
Кстати, я видел биллинговые системы, в которых счет изначально находится в состоянии «черновик» и имеет уникальный «идентификатор черновика», сгенерированный базой данных. Затем, когда он подтверждается и передается клиенту, создается строка в другой таблице с окончательными неизменяемыми данными, и ей присваивается окончательный «идентификатор счета», который снова генерируется базой данных. Затем проект и счет связаны между собой ключевыми отношениями в БД. Так что это один вариант для вас, чтобы обойти эту ситуацию. Опять же, это просто автоматически сгенерированное число, без лишних попыток создать бессмысленные искусственные последовательности и т. Д.
«Вы не обязательно должны делать все, что хочет клиент, если вы можете доказать им, что это не очень хорошая идея»: здесь я просто пытаюсь выявить проблему, не объясняя все системы, существующие вокруг. Требование клиента хорошее. Есть электронное управление документами и другие приложения, работающие с моим приложением. И да, у меня не должно быть дыры в моем списке сгенерированных идентификаторов, потому что, по закону, это требование ( service-public.fr/professionnels-entreprises/vosdroits/F23208 ).

DaBra · Answer 1 · 2018-07-27T08-34-00.000Z

Я бы сохранил текущий идентификатор в таблице db. Каждый раз, когда вы хотите увеличить id, выполните следующие действия:

Начать транзакцию
Заблокировать строку id в таблице db: в mysql использовать FOR UPDATE
Прочитать текущий идентификатор
увеличить идентификатор
сгенерировать счет с идентификатором
Сохраните идентификатор обратно в db
Зафиксировать транзакцию

SQL Hacks · Answer 2 · 2018-07-27T07-52-00.000Z

Я бы пошел на MAX (id) +1. Вы можете получить следующий номер в последовательности с запросом типа:

SELECT COALESCE(MAX(id),0) + 1 FROM bill
 WHERE society = 'XYZ'

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

Лично я всегда избегал триггера. Я никогда не использовал триггер и не сожалел об этом позже.