Где лучше генерировать uuid для базы? В коде или в sql запросом?

Question

[nakem]

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

Comments

[Akina]

Лучше в коде генерировать или в запросе функцией.

Лучше - с какой точки зрения, по каким критериям нужно оптимизироваться?

В коде - в каком именно коде? имеется в виду клиентский код? или сравнивается генерация непосредственно в запросе с созданием для генерации отдельной пользовательской функции, которая будет использоваться в запросе?

Вообще-то, чисто по сути и назначению - UUID вообще-то просто не должен покидать SQL-сервера, ибо клиенту с его значением делать нечего. Так что в упор не вижу смысла поручать генерацию кому-то ещё, кроме самого SQL-сервера.

Answer 1

[entermix]

В коде, потому что так проще проводить Unit-тестирование или связывать сущности

Comments

[Akina]

А какое отношение связывание сущностей, выполняемое SQL-сервером, имеет к клиенту? И какое отношения генерация имеет к последующему использованию?

[entermix]

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

[Akina]

чтобы можно было обернуть несколько запросов в транзакцию

Для справки. Те транзакции, в которые ты оборачиваешь запросы в коде приложения, на самом деле - транзакции, которые организует и выполняет SQL-сервер. Всё, что делает клиентский код при организации и выполнении транзакций - это передаёт SQL-серверу просьбу о транзакции. То есть, обычный паразит-посредник.

добавлять запись в базу данных, получать идентификатор и только после этого добавлять связанные сущности.

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

[entermix]

Akina, объясните, пожалуйста, как Вы собираетесь получить идентификатор (database generated id), чтобы связывать сущности без предварительного сохранения записи в базе данных?

[Akina]

entermix, вот очень интересно, с чего был сделан столь вопиюще странный вывод, что запись не будет сохранена в БД? когда всё с точностью до наоборот - UUID генерируется и сохраняется в БД, но не попадает на клиентскую сторону, ибо там он нахрен не нужен.

[entermix]

Akina,

с чего был сделан столь вопиюще странный вывод, что запись не будет сохранена в БД

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

UUID генерируется и сохраняется в БД, но не попадает на клиентскую сторону, ибо там он нахрен не нужен.

Если первичный ключ не нужен на стороне клиента (backend), то как связать новые сущности с только что созданной записью в базе данных?

[Akina]

entermix,

может произойти ошибка, например, в связи с недостаточной проверкой данных

Ну произошла ошибка... и что? Уйдёт багрепорт, код допишется и будет нормально проверять входные данные. До следующего багрепорта. Обычная ситуация.

Если первичный ключ не нужен на стороне клиента (backend), то как связать новые сущности с только что созданной записью в базе данных?

??? Связывание на основании первичного ключа как существующий объект - фикция.

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

А именно связывание на основании, как сущность, а не процесс - это всего лишь абстракция в нашем мозге.

PS. Всё обсуждение - имхо последствие попытки низвести SQL-сервер до роли тупого хранилища данных. И выполнять абсолютно всю обработку на клиенте. Тебе дали - храни. С тебя спросят - отдашь.

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

[entermix]

Akina, мне кажется Вы вообще не понимаете о чем идет речь.

Ну произошла ошибка... и что? Уйдёт багрепорт, код допишется и будет нормально проверять входные данные. До следующего багрепорта. Обычная ситуация.

Нет, не обычная, это может привести к нарушению целостности данных, что повлечет за собой ряд других ошибок

??? Связывание на основании первичного ключа как существующий объект - фикция.

Ясно [facepalm.jpg]

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

Вы так и не ответили, как Вы собираетесь связывать новые сущности с только что добавленной записью без дополнительного SQL запроса, который позволит получить ID записи?

PS. Всё обсуждение - имхо последствие попытки низвести SQL-сервер до роли тупого хранилища данных. И выполнять абсолютно всю обработку на клиенте. Тебе дали - храни. С тебя спросят - отдашь.

Именно так и должно быть, реализация хранения данных не должна быть тесно связана с бизнес-логикой приложения.

Сегодня Вы используете MySQL, завтра захотите PostgreSQL, потом Microsoft SQL Server и все эти автоматически генерируемые идентификаторы, триггеры, хранимые функции и другая логика принесут немало хлопот, поэтому учитесь проектировать приложение правильно. Нельзя, чтобы база данных управляла приложением.

https://medium.com/swlh/dont-use-database-generate...
https://medium.com/ingeniouslysimple/why-did-we-sh...

[Akina]

Нет, не обычная, это может привести к нарушению целостности данных, что повлечет за собой ряд других ошибок

Это произойдёт в случае, когда целостность данных проверяется клиентским кодом. Ограничения же в структуре данных в принципе не позволят сохранить данные, нарушающие эти условия-ограничения.

как Вы собираетесь связывать новые сущности с только что добавленной записью без дополнительного SQL запроса, который позволит получить ID записи?

??? Вы о существовании INSERT .. SELECT знаете? или всю жизнь пользовались только INSERT .. VALUES?

реализация хранения данных не должна быть тесно связана с бизнес-логикой приложения.

Вот об этом и речь. Ошибка в том, что Вы низводите сервер до уровня тупого хранилища. И не желаете признавать что та часть кода, которая располагается на SQL-сервере, является равноправной частью приложения.

Сегодня Вы используете MySQL, завтра захотите PostgreSQL, потом Microsoft SQL Server и все эти автоматически генерируемые идентификаторы, триггеры, хранимые функции и другая логика принесут немало хлопот, поэтому учитесь проектировать приложение правильно. Нельзя, чтобы база данных управляла приложением.

Вы сегодня пишете код на питоне, завтра захотите перейти на шарп, потом на джаву... в чём разница с утверждением про изменение SQL-сервера? ни в чём. У Вас выбранный язык (или даже фреймворк в рамках того же языка) управляет приложением - но это Вас как-то не беспокоит... Нельзя, чтобы выбранное средство создания приложения управляло приложением - Ваш тезис, просто применённый к тому, о применении к чему Вы даже помыслить боитесь. Так что не надо про "правильное проектирование приложения".

[entermix]

Это произойдёт в случае, когда целостность данных проверяется клиентским кодом. Ограничения же в структуре данных в принципе не позволят сохранить данные, нарушающие эти условия-ограничения.

Проверки целостности данных на стороне SQL-сервера снижают производительность.

Вот об этом и речь. Ошибка в том, что Вы низводите сервер до уровня тупого хранилища. И не желаете признавать что та часть кода, которая располагается на SQL-сервере, является равноправной частью приложения.

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

Вы сегодня пишете код на питоне, завтра захотите перейти на шарп, потом на джаву... в чём разница с утверждением про изменение SQL-сервера?

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

https://parpalak.com/blog/2019/08/06/no_business_l...

Счастливо оставаться в мире монолитов, где не применяют масштабирование, не тестируют и не профилируют код.

Answer 2

[Сергей Томулевич]

По большому счету - без разницы.
Но сильно зависит от того, каким образом осуществляется генерация UUID на клиенте.
Например, при использовании rand основанного на времени, я сталкивался с проблемой уникальности при плотной вставке записей в базу данных (при плотности записи больше 10К per sec данная ошибка будет проявлятся стабильно).

Answer 3

[nApoBo3]

На клиенте. Это пожалуй основная причина зачем использовать uuid. Вы его можете генерировать не централизованно.

Comments

[Beliyadm]

Генерить гуид на клиенте это худшее что я слышал в своей жизни