Здравствуйте, 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
