Номера записей в таблице без пропусков

Приветствую всех! Переодически, встречая подобные вопросы, у меня самого "лицо в руки падало", но вот и сам вляпался. Тот кто работал с заказчиками-мозгоё[цензура] меня поймет.
В общем, записи в БД имеют поле: `order_id` (AUTO_INCREMENT, PRIMARY KEY) и поле `order_num` (не уникальное и без автоинкремента). С первым всё понятно - оно исключительно для работы. А вот второе поле - "номер заказа" - может иметь значение "0", если заказ еще не принят в работу и, если уже принят, то порядковый номер. При этом не должно быть пропусков в нумерации, даже если где-нибудь из середины запись будет удалена.
Решения найденные мной, в большинстве случаев, совпадают с найденными в инете. Все они, как и сама задача, позитивных эмоций не вызывают, поэтому решил посоветоваться с сообществом и найти оптимальный выход из дурацкого положения. Основной принцип в найденных решениях: вытащить все номера, проверить на php присутствие "пробелов", если есть, то взять пропущенное число, если нет - то максимальное + 1 и записать в базу. Конечно "ужос, летящий на крыльях ночи", но жопаделать...

(Отредактировано автором: 13 Января, 2014 - 09:54:00)

Объяснить заказчику, что если заказу присвоен номер, то этот номер навсегда занят в системе, и не стоит его использовать снова. Гораздо лучше сделать поле-признак состояния заказа, в качестве номера использовать ID, и, возможно, добавить время исполнения.

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

-----
Чем больше узнаю, тем больше я не знаю.

Поинтересуйтесь у заказчика, каково должно быть поведение системы, если есть непрерывные заказы 1..10 и надо удалить заказ #4. Пересчитать номера? А если потом позвонил клиент и говорит "у меня заказ номер 7", то какой заказ надо смотреть?

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

Если почему-то действительно непрерывность требуется - то при удалении заказа только перенумеровывать все следующие далее.
PS: рекомендую order_num сделать null, тогда можно повесить уникальный индекс.

-----
PostgreSQL DBA

Спасибо, господа, за ответы. Решил сконцентрироваться не на поиске решения проблемы, а на сборе убедительных аргументов, чтоб этого не делать. Через пару дней заказчик возвращается и буду с ним бороться. В худшем случае, как посоветовал Мелкий, сделаю поле NULL. Что-то я забыл об этом, а хоть как-то, но облегчит задачку.

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

Лучше конечно заказчику какие-нибудь дыры заткнуть.