2013-09-25 5 views
0

Я присоединился к проекту, который использовал случайные числа, генерируемые клиентской стороной, для полей первичного ключа в базе данных mysql. Эти поля первичных ключей являются автоматическим приращением, но не используются как таковые.Пользовательский автоинкремент Mysql для исправления случайных идентификаторов

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

Теперь у нас есть разреженный массив значений id во многих таблицах и значительное количество ключевых столкновений при вставке.

Есть ли какая-то исправляющая работа, которую я могу сделать, чтобы база данных могла генерировать идентификаторы (например, начать с последнего выделенного идентификатора и найти следующий доступный идентификатор) и для следующего вызова JDBC?

numero = stmt.executeUpdate(query, Statement.RETURN_GENERATED_KEYS); 
+0

Чтобы иметь возможность предложить вам что-то практическое, вам нужно быть более конкретным и начать с публикации текущей схемы таблиц и указать, какой движок вы используете в настоящее время. – peterm

+0

@peterm. Хорошо, спасибо. В db содержится около 120 таблиц (для многих для перечисления), каждая таблица сущностей содержит единственный первичный ключ суррогата, который обычно является int (10) ненулевым auto_increment. Цель db - mysql 5.1.69. Иды «хорошо» распределены по диапазону идентификаторов, а также большие пробелы. Клиент jdbc является текущим. Существующий код страшен многими ошибками и связанными с этим проблемами качества данных. Я ищу архитектурный совет, который будет работать. Например. реализовать сохраненный процесс, обновить это поле метаданных последнего id mysql и т. д. Надеясь, что кто-то встретил это раньше и зафиксировал его? – karu

ответ

0

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

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

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

+0

Спасибо. Текущий max (id) для некоторых таблиц уже находится в верхней части доступного диапазона id из-за случайного распространения, поэтому мне нужно будет изменить схему, чтобы увеличить размер поля. Нет модели doco/domain, и идентификаторы являются внешними ключами во многих других таблицах, поэтому, если я пропущу одну схему поля внешнего ключа, все будет взорваться. Сказав, что я думаю, что увеличение длины поля и от max (id) +1 может стать моим лучшим вариантом. – karu

Смежные вопросы