Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
И, вдобавок, были реальные случаи совпадения MAC-адресов.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
"L1" (что, кстати, в случае ethernet вообще не совсем верный термин т.к. стандарт не подразумевает строгого разделения на L1 и L2 и формализует одновременно оба уровня) вообще ничего не содержит и не инкапсулирует. Это способ модуляции сигнала.
Напомните пожалуйста. Это тот самый Сэм Альтман, что отжал себе OpenAI (который почему-то не open и не AI)? Если да, то словам такого джентльмена нельзя не верить!
ВК за всё берется смело
Всё превращается в говно
А если за говно берётся
То просто тратит меньше сил
Три: пароль от сети заносится в keepass и проблема решена.
Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Приоритеты власть имущих они такие, да)
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
Но есть запрет на их полеты!)
Я так всю жизнь летаю. Но есть нюанс: я пялюсь в одну точку с закрытыми глазами 😁
Не содержит и не инкапсулирует. Кодирует.
Слово "transparent" должно намекать.
И нет. Оно в реальности почти никому не нужно кроме очень узких кейсов.
"L1" (что, кстати, в случае ethernet вообще не совсем верный термин т.к. стандарт не подразумевает строгого разделения на L1 и L2 и формализует одновременно оба уровня) вообще ничего не содержит и не инкапсулирует. Это способ модуляции сигнала.
Хосспаде, любой адекватный фаервол умеет в transparent mode работать. В чем функциональная инновация то?
Ну тут механизм примерно тот же, но мощность мизерная. А вот радиомачты - реально "страшно, вырубай!" 😁
Вообще легко. Идёте поближе к радиомачте на много десятков киловатт излучаемой мощности и буквально дуговой разряд на трос ловите)
Возможно и необходимо ездить в отпуск. Но не на две недели когда у вас кот один сидит
Не бывают. Это химеры с XXY хромосомным набором
Самая ленивая отмазка на свете
Чем дальше читаю, тем больше понимаю, что номер 69 отделу дали не просто так.
Напомните пожалуйста. Это тот самый Сэм Альтман, что отжал себе OpenAI (который почему-то не open и не AI)? Если да, то словам такого джентльмена нельзя не верить!