Если попадём в пропуск - получим максимальный PK до пропуска. Всё ок, валидное значение.
Накладка может быть только в случае, если мы будем подряд "лупить" в пространство PK более максимального значения, и многократно получать один и тот же PK. Решение: подбирать разрядность в соответствии с разрядностью ключа. 2 декабря 2013 г., 20:55 пользователь Михаил Монашёв < [email protected]> написал: > Здравствуйте, Andrei. > > > если в данный момент максимальное значение ПК = n, то для каждого X > существует одно, и только одно максимальное значение ПК, меньшее n. > > > > допустим, в данный момент n = 60000. это значит, что 2 байта покроют все > значения PK. > > > > откусываем 2 байта от хеша. получаем, к примеру, 60001. неудача! > сдвигаемся на бит (или байт) вправо; получаем 54467. ура. выбираем > максимальное значение ПК из таблицы, меньшее 54467. > > > > допустим теперь, что в таблицу добавили ещё одну строку, и при повторном > запросе 60001 будет считаться валидным значением, в результате выборка > поменяется. > > > > ОК, workaround: сохраняем значение PK 60000, ассоциируя его с этой > строкой. при последующем запросе берём ИЛИ сохранённое значение, ИЛИ (при > его отсутствии) максимальное значение PK. > > Не нужен здесь workaround. 60001 просто станет отображаться в новые > id-шки. а большинство будет отображаться в старые. т.е. изменения > коснутся только 1/60001 часть строк. > > Так что решение нормальное. > > А вот попадание в пропуски или в неподходящие объекты не годится, ибо > может в теории работать бесконечно долго, т.е. количество итераций в > нем не конечно. > > -- > С уважением, > Михаил mailto:[email protected] > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Best regards, Andrei +7-937-847-60-74
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
