HostiMan.ru - Бесплатный NVMe SSD хостинг №1 в России - 5 лет и более 160 000 клиентов!

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

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

Ещё раз. Если вы не сталкивались с багами (да, в бездну от этого ничего не улетит и вряд ли сломается), это не означает, что не столкнетесь с ними в будущем. Все остальное даже смешно, если бы небыло так грустно. Этот холивар начался с того, что кто-то сначала не верно понял что у вас стоит, потом выразил мнение. И обосновал его. А дальше ваше дело, реагировать ли и как реагировать.

Мой - настоящий. :)

Zevss, Да мы уже разобрались, что там чудная настройка биллинга ;)

На самом деле [если какая-нибудь неприятность может произойти, она обязательно случиться. Закон Мерфи] нормальные разработчики ПО знают о вероятности и никогда не допустят такого. Возможно в панели эти задачи возложены на СУБД (уникальные ID в базе) и тогда проблем не случится, но тоже дурость - проще инкрементно выдавать номера.

SeVlad, гипотетическая проблема начинается вбиванием в поиск номера тикета и заканчивается датой и его содержимым. По ссылках не тикеты проблема невозможна.

Ну если мы соберем всех хостеров одной страницы SE в одну базу, их количество тикетов в день, то вероятность повторения номера за 1 год даже не равна 1%.

Сразу видно менеджера, совсем далёкого от обработки данных. :)

Ок. Объясню.

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

Если это не уникальное, то при записи проблемы [может быть] не возникнут, но могут возникнуть при обработке. Чтобы они меньше возникали - наборам таких записей нужно присваивать уникальный ID и работать уж с ним. А это доп ресурсы как по написанию кучи кода, так и по работе самого ПО. Так зачем этот гемор, если можно сразу присваивать уникальные ID инкрементно?

И уже потом появляются проблемы, описанные тобой. Гипотетические или нет - это вообще не важно. Это может произойти? Может. Так вот если может - нормальные разрабы такого просто не допустят.

Выше же уже объяснили, что TID тикета показываемый клиенту отличается от ID тикета, используемого как индекс для записи в БД. От того, что TID гипотетически повторится - ничего не сломается. И при обработке данных можно использовать реально уникальный ID, а не TID. Какой смысл мусолить эту тему с теми, кто далек от кода и логики WHMCS?

Может в базе и не "сломается", а вот при поиске-обработке может сломаться мозг саппорта и отношение с клиентами.