- Папа, я просто хотел поиграть в машинки...

опять все переделывать

uuid нужен не для безопасности, а чтобы гарантировать что в распределенных системах данные можно будет склеить без спецэффектов, особенно всё что связано с "оффлайн" режимом (например генерировать связанные по uuid данные в разных таблицах на клиентах, а потом синхронизировать в общую базу, например в iot это повсеместно или например в ритейле, где касса может пробивать чеки в оффлайне, а потом синхронизироваться с сервером)

По-моему автоинкремент не безопасен только в случаях, когда нужно избежать возможности перебора. Например пользователей. Если же данные по кругам и заездам являются полностью открытой информацией, то не вижу ничего плохого в автоинкременте.

Не упомянули про uuid v7, его как раз удобно использовать для шардирования

Замените, пожалуйста, заголовок на "UUIDv4 замедляет ваши приложения и сайты", чтобы не вводить людей в заблуждение, так как это всё не имеет никакого отношения к UUIDv7😡

ожидал бенчмарка, а тут какая-то демагогия

Для начала нужно опреоелиться, какой опасности вы пытаетесь избежать. Если вам нужно избежать несанкционированного доступа к объекту, то uuid для айдишников тут не поможет. Не надо безбумно применять модные паттерны.

4:25 о какой базе данных речь? Реляционные базы не будут ничего "перекластеризовывать" при добавлении, да и при удалении и редактировании тоже. Каждой записи в таблице базой в любом случае будет выдан скрытый целочисленный идентификатор, который иногда может совпадать с видимым.

А если айди генерируется на клиенте? А если я хочу гарантировать отсутствия совпадений и коллизий? а если я не хочу думать о том что я переполню когданибудь счетчик?)

Что мешает шифровать числовой индекс? Будет сохранено уникальное 32 битное число, но со скрытием его исходного значения (если надо было скрыть количество или порядок).

Никто не запрещает вам использовать то и другое одновременно, внутри сервиса обычный bigint выставляя данные наружу с uuid aka external id

интересно приолжение с машинками посмотреть теперь) как сделал чтоб камера счиытвала цвет??

5:39 а как же индексация? вместо автоинкрементируемого id можно использовать timestamp условный "created_at" они тоже по очереди идут

Миша, чем обрабатывал видео и анализировал цвет машинки?

а еще можно немножко подумать и прийти к просветлению что: 1) не обязательно и текущий онлайн гонки и статистику по прошлым гонкам хранить в одной структуре 2) структура данных и тип таблиц для статистики и текущего онлайна не обязательно должна быть одна и таже. я даже больше скажу - єто совершенно разные задачи. и т.д. и т.п.

В свое время Михаил Задорнов сказал следующее - "Никогда не говори со сцены то, за что тебе было бы стыдно перед твоей матерью!" Рядом с этой надписью можно поместить высказывание Михаила Ларченко - "Никогда не пиши код, который тебе было бы стыдно выложить на Гитхаб!" 😀

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

типа данные о заездах это пример супер конфиденциальных данных? и они ну никак не уживутся с обычными целочисленными ключами?

Плюсы uuid в том, что можно создать инстанс доменного объекта сразу с известным Id, не завися от базы данных или её отсутствия.

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

Прикольно, не знал таких нюансов 👍

хз,даже для POS приложения оставляю пока bigint (в PG) поле (если точнее то bigserial) а вот для транзакций уже использую время ориентированный уид (самописный уид в7,когда он еще был РС) он также хорошо индексируется

Чё то я не особо понял почему автоинкремент это не безопасно, тип из-за перебора так а почему нельзя ограничить вывод информации из бд даже для перебора и настроить несколько уровней доступа, что бы условный перебор не работал? Может кто в кратце пояснить?

ролик ниочем. экономия на спичках.

Лайк в поддержку канала

UUID не обязательно должны быть полностью случайными. В качестве примера, часто предлагается брать часть первых битов (те же самые, например, первые 32 бита) от текущего временного штампа, а остальное - генерировать случайно. Таким образом, БД сможет сравнивать и упорядочивать записи по времени. А новые записи всегда будут добавляться в конец. Не использовать 128-битные числа вместо 32-битных, в то время как в большинстве БД основную часть места занимают всякие строки, где каждый символ уже будет занимать 16 бит - это уже экономия на спичках. Современные БД позволяют сравнивать 128-битные числа аппаратно между собой без дополнительных программных преобразований. UUID это все еще числа, но они не увеличиваются на +1, и их не надо парсить. Может быть, UUID в каких-то определенных БД и проигрывают по производительности простым целым инкрементирующимся числам, однако в результате 10-минутного гугления я не нашел убедительного сравнения на этот счет. Сравнивались методы построения UUID (и полученные производительности), или говорилось опять же что "ну знаете, у нас вот тут случайные UUID, они занимают больше места, а еще вставляются в случайный кластер", но вот именно сравнение производительности обычного инкремента и хорошо построенного UUID - я сходу не нашел.

Автор или тот, чью статью он пересказывает, не понимают, зачем нужен UUID, и критикуют использование ID. Если у вас много систем и хотя бы две базы данных, правильно использовать уникальный ключ. Данные могут храниться в разных местах, но утверждение о том, что обычный инкремент небезопасен, является необоснованным без конкретных примеров. Если система работает медленно, можно улучшить её производительность различными способами: добавить индексы, обновить оборудование или выбрать другую базу данных, которая лучше подходит для быстрого ввода и хранения данных с последующей обработкой. Использование UUID в проекте может показаться излишним, особенно если не ясна цель его применения. Важно чётко понимать, зачем нужно то или иное решение, а не просто добавлять функции без необходимости.

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

А зачем внешняя база данных для машинок, если можно хранить записи локально в браузерной IndexedDB?

Если испоьзовать 4 версию, то да, замедляеся, и так же нормально ни в индекс не ляжет испльзуйте 6 или 7 версию как написали выше. А так же хранить данные строкой странно, бинарными данными хранить, то будет всего 16 бит, отличие от bigint всего в 2 раза.

Ну можно предсказать и что? Безопасность надо делать на другом

Можно код считалки гонки?

А в чём не безопасность цифрового детерминанта? Какая проблема сделать SQL запрос select max(id), и в ручную увеличивать на единицу? Опять же uuid, штуковина которая нужна для распределительных систем, если один и тот же сайт висит на 50-ти серверах, и INSERT запрос может случиться на любом из них. При числовом id, при синхронизации будут коллизии. Можно вообще вычислять по sha256, абсолютно уникальный hash на 64 символа. Но ещё раз возникает вопрос, зачем оно нужно, если система не распределённая?

Авто инкремент безопасен, просто не отправляй его на фронт а используй слаг

Где проект, дайте сдать пул реквест!

Главное uuid как key не использовать в React приложениях ))

UUID - глобально уникальный идентификатор, и единственный минус атоинкремента перед uuid это в том, что нет этой самой глобальной уникальности. То есть, если вы не планируете шардинг, чтобы масштабировать свои данные на несколько баз данный, то вам такая уникальность не нужна. В рамках одной БД счетчик автоинкремента свою работу выполняет на 100%, и во всех прочих аспектах с интами работать проще чем с uuid.

что-то не очень понял логику типа функционал определения цветов неидеален, но пойдёт, тк для домашних целей, а простой инкремент в бд не устроил, тк уже небезопасно 🤔

Не приходилось вам ебстись со сбитыми последовательностями и сформированными наборами данных в таблицах. Но в целом подход правильный - если система локальная для одного разраба, а то и одного пользователя, то uuid - избыточен. А генерация уникального идентификатора на клиенте очень помоагет в некоторых случаях работы с данными на бэке.

2:25 говорит, что автоинкремент считается небезопасным. Просто считается и все, а потом кто-нибудь скажет, что считается кем-то из этого видео. В качестве индексируемого поля GUID плох тем, что индекс вынужден из-за него быстро фрагментироваться, а особенно, если кто-то хочет генерировать его не на стороне базы данных, а самостоятельно. Для того, чтобы выбрать между автоинкременом и GUID нужно четко понимать, для чего производится выбор, универсального решения в данном случае нет. 2:52 "uniqid" две ошибки в одном названии вместо "uniqueId".

та всі випадкові числа, які генерує комп'ютер не є випадковими на 100%.

Ого , не сложное приложение 😅 Звучик классно

Что??? UUID уже не хэшируются? Их уже нельзя использовать в хэш-таблицах? Нельзя быстрый поиск там, сортировку по ним делать? В сегодняшнем 64-битном мире 128 бит UUID это очень тяжелая структура? Накладно ее в базе данных хранить, где нужны абсолютно уникальные идентификаторы? Серьезно? Машинки будут медленнее регистрироваться и база данных домашних гонок распухнет до террабайтов из-за UUID?

ты забыл упомянуть почему считается не безопасным - только в том случае, если у вас есть публичный api по этим ID. например есть профиль юзера который по ID показывается. Но есть другие способы решать эту проблему. UUID нужен для распределенных систем да и только :) для твоего кейса будто монго подходит, ведь у тебя толком реляционности нет, скорее куча документов - записей кругов, как история

generate time based UUIDs

Nano UUID можно на меньшее кол-во знаков

100% должны быть uuid которые monotonically increase чтобы решить проблему database index

загрузил = лайк получи

Все это очень сомнительно по поводу скорости. Когда база данных будет делить на кучки при создании индексов, то разница между делением числа (id) или строки (uuid) будет не такая большая как мне кажется. В любом случае проще забить миллион другой записей в базу и потестить. Но судя по этому ролику у вас весьма скромные познания в базах данных.

Ююид тоже много что показывает - идентифицирует "источник" - часть юида ни когда не меняется в конкретной системе, часть просьо инкрементируется. Так что ююид это вообще не про безопасность а про шардинг.

Кто видел Кисо, ставь лайк! 😂

купи ребенку компик и скачайте фолыч с рутрекера

Какая тебе нафиг безопасность нужна в этом приложении, зачем переусложнять все. А если нужна безопасность, поверх внутренних ID можно навертеть логику публичных ID. UUID нужны не для этого. А для того чтобы можно было генерировать их отдельно от базы. Если это не требуется, то и UUID не нужны.

- uuid замедляет ваше приложение *пишет код на JS* Я не буду обьяснять насколько дурная чуш в видео - просто скажу, что не увидел ни одного перфоманс теста на озвученные предположения. Мне точно так же в начале карьеры пытались доказать что "SQL джойны медленные". Если у вас тормозит база - значит вы не умеете её готовить.

может ребенок не может найти фаллаут 3 из-за того, что эта игра старше него...

Конкретному инструменту конкретное применение. В иных случаях при планировании бэка и бд волосы дыбом встают от мысли использовать в качестве ключа автоинкрементный счетчик) Недавно писал приложение с возможностью работы как в онлайн, так и оффлайн режимах. Создание сущности на клиенте в оффлайне приводит к необходимости проверки коллизий при синхронизации и коррекции ключевых значений (ужас ужасный). Uuid явно более применим.

с ююд4 можно получить время, уже не безопасно

очередной наркоман в своём делирии нашёл ответ на вопрос жизни, вселенной и всего

uuid только для внешнего взаимодействия

Бла бла бла, Никаких доказательств. Использую uuid во всех проектах. Никакий проблем не замечено.

Миша, на тебе свитер висит как на вешалке.. 😮 Тебе мешок картошки из Беларусии прислать?

6-ти минутное видео, укладывающиеся в два слова "uuidv4 медленный". Можно ещё двух часовое видео "почему fgets - опасно"? зачем..?

Более менее современный код, это код который 99% всего времени делает какую то хрень вместо полезной работы.

Ну и балабол! Дядя ты тесты и цифры предъяви! На таблицах до 1М разница не более 5% по моим расчетам.

UUID7 (7-й версии) спасет отца голландской демократии!

Что за бред он несет?

быстрее удаляйте этот ролик. Такое ощущение что вы отец одиночка с грудным ребенком, от недосыпа кукухой поехали. Монолитные решения не используют uid. Там слой сохранения всем всё присваивает. Для DDD решений uid обязателен. Не во всех агрегатах та же структура вложенности сущностей. Потому связывать их событиями не так то просто без uid, нужно тогда организовывать функции проекции айдишника в событии из одного аггрегата на другие. А это засорение логики домена, раздувание исходного кода и куча багов. За такие ролики вас могли бы и уволить в нормальной компании. да и при вложенности сущностей в структуру аггрегата скажем тремя слоями полный ид нижней сущности без использования uid будет уже не 32 бита а 3х32

"автоинкрементные id небезопасны для домашней поделки для учета гонок машинок". Дальше можно не смотреть.

const getUID = ((count, last_time, last_uid) => () => { const time = (new Date).getTime(); if(time === last_time) { return last_uid + '-' + (count++); } count = 0; last_time = time; return last_uid = time.toString(36); })(0);