Пусть есть таблица




При этом логика нашего клиентского приложения предполагает хранение в этой таблице айдишников, которые больше 100000 и меньше 999999, то есть всегда шестизнак.

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

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

Вопрос: может есть какие-то секретные шняжки для решения подобной задачи?
Типа как бы аналог auto_increment, только типа как бы типа такого

tanglirа надо "настоящий" ранодом или и псевдо устроит?

вопрос не понятен....
прошу уточнить...

ScareCrowгенерить рандомное число, выбирать первое несуществующее больше него.

а каким запросом узнать первое несуществующее число больше 463504?

tanglir


Благодарю!

Тут ещё ограничитель сверху до кучи




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

PS. кстати, а просто для общего развития, что имелось ввиду под настоящий или псевдо-рандом?

miksoftЕсли действовать только средствами MySQL, то я бы заготовил заранее перемешанную таблицу на нужное количество записей. Перемешать можно с помощью ORDER BY RAND(). Это очень не быстро, но для разового выполнения сойдет.

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

1) Для меня это новая идея, что создание некой новой сущности в системе - это не insert + update, а такая разновидность update, которая скидывает флаг "isBlank" в ноль....

правда теперь придется обмозговать какие это внесет дополнения в стиль работы
например, теперь вместо select * from t придется делать select * from t where isBlank = false просто для того чтобы узнать количество записей

2) order by rand() тут наверное лишний, потому что для создания такой таблицы лучше на клиенте создать массив и перемешать его, а затем уже проинсертить все 899999 пар (id, seqId) и для активации ("создания") новой записи просто искать минимальный seqId с флагом isBlank = true

miksoftМожно и так. А можно просто удалять из таблицы использованные значения.

miksoftКстати, а зачем тут поле id? не вижу в нем необходимости.

может я опять криво объяснил с самого начала
ситуация такая

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




все круто, все как обычно...
но в этой задаче номер животного может быть только [100000, 999999), то есть только шестизначным числом (это полбеды, ведь можно было бы просто прокрутить auto_increment до 100000 и поехали... в этой задаче важно новым животным присваивать номера случайным образом

поступила например лошадь



только вместо null нам важно присвоить какой-то случайный номер из диапазона [100000, 999999) и чтобы этого номера ещё не было бы в этой таблице

вот в чем ситуация...

поэтому я думал вы предлагаете сразу в этой таблице создать 8999999 животных, у которых id будет распределен случайно, а вот seqId будет последовательным и когда мы хотим занести в таблицу новое животное мы будем брать запись по номеру seqId (минимальный номер у которого флаг isBlank = true), затем по этому номеру получать id (который и является уже заранее занесенным случайным числом, затем скидываем флаг isBlank в false и по этому id прописываем все данные на новое животное

я думал вы именно такой вариант предлагаете...

miksoft, ок, теперь понятно.

Alex_Ustinovфизический смысл

Что означает термин физический смысл ?

Я от tanglir до сих пор не получил ответа что значат его термины "настоящий" рандом и пседорандом , а тут вы ещё какой-то физический смысл...

развели тут зоопарк терминов )

Alex_UstinovТ.е. каково дальнейшее применение?

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

Ну например, если бы у нас таблице был бы автоинкемент, начинающийся от 100000 и было бы уж 500 животных, то если мы создавали обычным бы макром, то 501 животное получило бы номер 100501, а в нашем случае номер будет какой-нибудь типа 430564 или 676133, а животных все равно 501.

Есть же разница: либо у вас в клетке живет 5 попугаев 100354, 100355, 100356, 100357, 100403
или у вас в клетке живет 5 попугаев 156105, 679313, 456321, 546689, 901636.

Вот.

Alex_UstinovЗачем именно РАНДОМНЫЕ "бирки"?

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

Перепутать 654321 и 467963 гораздо сложнее.
Мозгу физически труднее спутать эти два числа даже не читая их по отдельным цифрам.

Alex_Ustinov(это точно не id в понятии СУБД)

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

tanglirLumixЯ от tanglir до сих пор не получил ответа что значат его термины "настоящий" рандом и пседорандом Это потому что я нестрого эти термины использовал - вообще-то даже то, что я называл настоящим рандомом по сути псевдорандом :)
"Настоящий" - это когда невозможно выявить закономерности в случайных данных, даже если эти закономерности НСД имеются в нашем ГСЧ. Насколько я знаю, большая часть ГСЧ в писюковых ЯП - это по сути псевдорандом. Сид у них ещё может быть по-настоящему случайным, а вот дальнейшая последовательность строго определена сидом. Хотя "на глаз" она вроде как случайна.
А "псевдо" - это когда метод генерации СЧ настолько хреновый, что эти закономерности видно, как говорится, невооружённым глазом.
Вот сравните ваш вариант (генерим разные СЧ пока не найдём незанятое) и предложенный вариант (берём наименьший из тех незанятых, что больше одного сгенерённого СЧ).
Допустим, заполнили мы половину имеющегося диапазона тем и другим методом, ну и что исходный ГСЧ - хороший, "настоящий". Так в первом случае распределение будет такое же, как у исходного ГСЧ - более-менее равномерное. А вот во втором случае у вас будет много непрерывных последовательностей, много дырок между ними и немножко отдельно стоящих чисел. То есть распределение будет не сказать чтобы такое уж случайное.

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




невооруженным взглядом можно заметить закономерность...
либо вы Линус Торвальдс с лурки )
либо мои аналитические способности находятся на уровне хоббита с Флореса...
потому что для меня эти данные являются достаточно рандомными...

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

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

То есть выражаясь в ваших терминах эта проблема не является официально признанной проблемой.

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

Alex_Ustinovprimary key (id) - это не поле для хранения "бирок"

А вы докажите.

Мне почему-то кажется, что вы заколебетесь доказывать этот тезис.

Alex_Ustinovкогда вы это поймете - вопросов и к вам и ваших будет меньше.

А что вы мне конкретно предлагаете сделать?
Сесть в позу лотоса и медитировать до полного просветления?

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

Alex_Ustinovа в моей жизни "id" вообще неприменимо, primary key (id) - Понятие СУБД

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

Alex_Ustinovнасчет "визульного" разброса можно было сразу озвучить

Ага, щас.. ))))
я же знаю как тут на форуме все устроено...
закидали бы меня какашками с самого начала...

а так, я прикольный инструмент узнал про селф-джои на идентификатор с инкрементом

я считаю то, что предложил tanglir - это реально прикольный причендал, который может работать на ЛЮБОЙ диапазон айдишников не только на 900 тыс., но его можно использовать и на несколько миллиардов айдишников не создавая при этом таблицы на несколько миллиардов заранее

tanglirНовым способом - а тут вероятность того, что они получат последовательные номера, повыше. Причём чем больше номеров уже использовано, тем это вероятнее.

Повыше ) ну и слово...

Чисто из спортивного интереса, вопрос для тех, кто силен в теории вероятностей:

какова вероятность для нового попугайчика получить рядом стоящий номер с другим попугайчиком, если в таблице уже 8765 животных, а всего животных может быть только 899 999 (то есть 900 тыс. - 1)

я просто в теории вероятностей "школьник" и мне почему-то кажется, что вероятность будет

1 / (899999 - 8765) = 0,0001%

то есть как бы с этим можно "идти в бой"
хотя может я что-то в математике этой ситуации не так понимаю...

Alex_Ustinovполе бирка должно быть уникальным, а не примари


я не совсем догоняю что означает эта фраза...
если честно, то я не совсем даже понимаю, что такое primary key
то есть я не понимаю откуда он исторически появился...

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

tanglirВот, смотрите сами, что на миллионе записей при половинном заполнении выходит:
мин-макс длина цепочкиколичество в вар. 1количество в вар.22-5117285864296-1075381495311-15234272816-20462621-30021631-1000000015Цифры каждый раз, ясное дело, немного другие, но их соотношение сильно не меняется.

не хватает силы мозга распарсить сие творениче
что есть длина цепочки?
что есть вариант 1 и 2
что означает кол-во в каждом из вариантов?
можете ли вы как обычно делают в науке после таблицы сделать свой вывод?

tanglirА по первому шанс остаётся неизменным.

Я слегка запутался какой из вариантов первый, а какой второй.
Ваш на джоине с инкрементом - это первый, а миксофтовский на предвычисленных значениях второй.
Такая нумерация вариантов?

tanglirНет, первый - это ваш. Честный рандом. Ну и миксофтовская его модификация. Суть у них одна в общем-то.
А второй вариант - это "поиск первого незанятого".

ок, понятно

а можно как-то без ущерба для здоровья оптимизировать ваш вариант каким-нибудь order by random() чтобы приблизить эффективность к предвычисленным таблицам или к обычной проверке свободной ячейке в цикле? Потому что ваш вариант дюже приятен для очень больших номеров (миллиардников)

Alex_UstinovLumix,

циферки есть циферки, если уж беспокоиться о "бабе Нюре", то можно продумать какие то словестные комбинации для рандомной "бирки"

Ваша идея понятно.
Давайте её попробуем.
Предложите какой-нибудь вариант.
И сравним его по эффективности с нашим вариантом, где бирки идут в разброс.
Итак, в потенциале у нас 899999 бирок для животных (столько конечно не будет никогда, но в потенциале они есть).
Итак, какие именно словесные комбинации вы предлагаете.