сабж) Собственно, два вопроса: 1. Какой тип поля выбрать для UUID если я хочу использовать его в качестве primary? 2. Стоит ли это вообще делать, если планируется 1m записей и больше? У кого-нибудь есть такой опыт? Насколько оно будет медленнее при выборке по id чем обычный INT? Спасиб)
Кто-нибудь может сказать что такое высоконагруженные системы? --- Добавлено --- https://github.com/spatie/uuid-mysql-performance
спасибки!) самое то! --- Добавлено --- Правда сама тема сохранения в виде BIN немного мозг порушила Код (Text): CREATE TABLE `normal_uuid` ( `uuid` BINARY(16) NOT NULL, `uuid_text` varchar(36) generated always as (insert( insert( insert( insert(hex(uuid),9,0,'-'), 14,0,'-'), 19,0,'-'), 24,0,'-') ) virtual, `text` TEXT NOT NULL, PRIMARY KEY (`uuid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; нужно будет потом покурить какой-нить мануал по теме, и найти готовый класс для всего этого )))
Ну по твоим месагам я предположил что у мускуля костыльно генерится uuid, поэтому сказал за постргес, что знаю у него это есть наверка. Но ошибся.
Начал читать - сходу замечание)) Str::uuid(); Это хелпер - генерит именно 4 версию. Мало того, есть вообще такая красота Str:rderedUuid() The Str:rderedUuid method generates a "timestamp first" UUID that may be efficiently stored in an indexed database column: use Illuminate\Support\Str; return (string) Str:rderedUuid(); )))) Я кстати узнал совсем недавно о нем - раньше тож пришлось как-то свой генератор набросать - хотя он был другой совсем - не как у него --- Добавлено --- Ахах)) со смайлами смешно получилось))) --- Добавлено --- ...но вообще почитав увидел что народ рекомендует таки постгри потому что там uuid это специальный тип поля т.е. без танцев с бубном)))
я не подумал что это так просто)) думал какие-то преобразования из текста в бинарный формат нужны или типа того
Любая строка есть набор байтов. Как раз более сложные типы, такие как VARCHAR, заставляют базу производить дополнительные операции над данными. А бинарные типы BINARY и BLOOB сообщают базе, что в эти поля нужно записывать строки "как есть" и читать, сравнивать, так же. Поэтому в этих полях, Е и Ё всегда будут считаться разными, потому что это разные наборы бит, а не одинаковми, как в varchar с collation *_general_ci где данные рассматриваются базой именно как текст. Сами по себе строки не содержат информации, как с ними работать, они всегда бинарны.
Спасибо. Но я еще раз уточню: То есть в запрос INSERT просто передать текстовое значение '123e4567-e89b-12d3-a456-426655440000' и всё? Этого достаточно? Я конечно попробую, но мне кажется что либо Лара либо БД ругнется на тип данных))
Да, дело серьезное, требует обстоятельной подготовки. Налей себе чайку или чего по-крепче. Прочитай гайд по лучшим практикам составления запросов к последней версии MariaDB. Набросай от руки структуру таблицы. Будь уверен, что все поля расставлены в логичном порядке, и ни одно не пропущено. Не спеша набери SQL запрос. Проверь синтаксис, расстановку ключей и что ни один из них не будет длиннее 192 байтов. Не забудь про кодировку и сравнение для всей таблицы, но не устанавливай их на поле uuid. Вместо этого, задай ему тип BINARY и длину в 36 байтов. И самое главное - первичный ключ. Всё. Можно выдохнуть, закрыть глаза и жать Enter.
)))))))))))))))))))))))) мерси-мерси! --- Добавлено --- ...я кстати Марию потому и снес с виндовой локалки (она в XAMPP по умолчанию стоит) что из-за этих 192 байтов приходилось каждый раз патчить свежую установку Laravel - вроде пустяк, всего одно лишнее телодвижение, но в конце-концов оно меня достало, поставил MySQL
вообще-то binary(16) а не binary(36) ну вставка будет так INSERT INTO table (UUID) VALUES (UNHEX(REPLACE(UUID(), "-","")))