Как сделать случайное имя пользователя?

Question

[Айнур Ярулин]

Здравствуйте, есть таблица пользователей и я хочу, чтобы имя пользователя генерировалось примерно в таком виде: "Пользователь #5044"

create table public.profiles (
  id uuid not null,
  username text default 'Пользователь #' + рандомное и уникальное число

  primary key (id)
);

Comments

[Алексей Черемисин]

Кажется, программно, например на питоне, это сделать напорядок легче..

[Айнур Ярулин]

Алексей Черемисин, да, на клиенте я могу легко сделать это, но мне кажется, что более правильно делать это на стороне сервера. Может я не прав

[Jack444]

мне кажется подход изначально неправильный, сделай отдельное поле типа serial и потом когда тебе понадобится в запросе обьеденишь эти 2 строчки

[alexalexes]

Пишите триггер на вставку данных, в котором будете генерировать username по любому удобному правилу в рамках процедурного кода хранимых функций, либо игнорируя значение от insert, либо когда это новое значение null. Уникальность поля можно обеспечить constraint-ом.

[Алексей Черемисин]

Айнур Ярулин, Ох, у меня есть что сказать...
1) Зачем лишний раз нагружать базу? Если программно это делается быстрее, на порядок!
2) Не нужно писать ничего, что будет отлично от кода приложения. Ибо это нужно поддерживать на стороне базы, верифицировать, как-то таскать, загружать, версионировать, отлаживать...
3) Не нужно, желательно никогда-никогда, использовать триггеры! Делайте это программно и см. 1) и 2)
Касательно отдельно триггеров - большая часть ошибок от них... Их нужно включать-отключать при любой мало мальски большой переливке данных, иначе они так натриггерить могут, что у пользователей, и у руководства, волосы подмышками колом стоять будут.
4) Хранимки, триггеры и прочая ересь изжили себя лет 15-20 назад, когда клиенты были тупые и маленькие, а серверы большие... С хранимками и триггерами (а с ними особый разговор)
5) Код на порядок легче поддерживать, а базу партицировать, шардитовать (и что там еще в этом вашем хайлоад), когда нет лишних, не зависящих от бизнес-логики сущностей, которые нельзя контролировать в основных потоках приложения.
6) Умножение сущностей ведет к умножению ошибок.
7) Я запрещаю пользовать триггеры и хранимки, ибо они непредсказуемо влияют на нагрузку базы, которая создана для обеспечения консистентности данных...
Х) Ах, ну да, подзабыл... Как будете переводить триггеры-хранимки, если вдруг захочется поменять базу данных?
8) далее дискуссию продолжать не буду, хотите тригерры и хранимки - только не со мной.
И 9) Всякие новомодные ORM с триггерами почти несовместимы, ибо пишем в базу одно, а получаем другое, со стороны приложения закешировано третье...
https://qna.habr.com/q/270160
https://www.osp.ru/winitpro/2015/02/13044724

Ну и напоследок. Всегда задавайте себе вопрос - могу ли я обойтись без триггеров и хранимок, могу ли я это сделать без них? Если ответ Нет, то его мне очень и очень сильно нужно будет обосновать, и за последние 15 лет так никто и не смог этого сделать.

[Jack444]

Алексей Черемисин, тригеры для логов и статистических данных норм использовать, вот типичная задача, парсим прайс поставщиков и при изменении цены нужно в отдельную таблицу отправить id товара, id поставщика, старую цену, новую цену и дату, кроме того новую цену нужно обновить в основной таблице, поставщиков может быть десятки, под каждого поставщика отдельный асинхронный парсер берёт от 10-100 товаров на страницу, у каждого поставщика может быть как тысячи так и милион товаров, большая часть товаров у поставщиков может пересекатся. Как по мне проще 1 раз накинуть тригер на апсерт чем одну и тужу логику прописывать во всех скриптах

[Алексей Черемисин]

Jack444, Во первых, во всех скриптах прописывать не нужно (библиотеки и принцип SOLID), просто скидывайте куда нибудь в кафку или в nosql, подключайте воркеров сколько не жалко, или сразу пишите куда нибудь в TSDB.
1) Все равно это статистика,все равно не нужно до сотых граммов
2) Если и нужна точность, то у меня будет другая система, не зависящая и не трогующая данных биллинга, а тем более лицевых счетов.
3)Не будет никаких задержек и непонятных внутренних эффектов типа блокировок, откатов транзакций ( мне же из всех этих "статистических таблиц откатить надо")...
4) Не будет никаких эффектов с восстановлением из бекапов или шардированием базы
5) Если не хватает вычислительных ресурсов, их всегда легко добавить, база при этом будет гораздо спокойнее.
6) Отладка будет шелковистее, а то засандалил проводку, а база хрен знает что внутрях вертит...

В общем, да триггер повесить просто. Но это как кол себе вбить, вроде бы и кепочку держит, но головой не шевели.
Так что Ваш пример абсолютно неубедителен.

Ну и что касается OLTP - чем больше триггеров на базе, тем реакция системы непредсказуемее.
А считать статистику изменения цен можно и в памяти в потоке, изредка подгружая предыдущие значения. При этом это будет на порядок быстрее триггера: ибо не пишем, а читаем (а если и пишем, то только разницу или результат), нет лишних запросов (и транзакций), база не тормозит...

Да, еще такой вопрос - хорошо, если постгрес, а если покупная база?! С лицензией на per-CPU? Еее тригеерами нагрузить - себя в ад отправить, ибо лицензию за 10 минут не купить, а воркеры я даже на офисных компах могу назапускать.

Answer 1

[Дмитрий]

create table public.profiles (
  id uuid not null,
  username text default concat('Пользователь #', random()*100000),

  primary key (id)
);

Comments

[alexalexes]

Еще нужно обеспечить 100% уникальность.

[Дмитрий]

alexalexes, случайность и уникальность несколько разные вещи. можете повесить unique constraint. Можно к полю добавлять текущие миллисекунды, при маленькой вставке - вполне даст уникальнгсть
А можете завести отдельный sequence под это поле. Если все это не устраивает - ну делайте триггер, который будет проверять и генерировать.

Answer 2

[Slava Rozhnev]

CREATE SEQUENCE profiles_seq START 1;

CREATE OR REPLACE FUNCTION nextval_rand(regclass)
  RETURNS text AS
$func$
BEGIN
EXECUTE format('ALTER SEQUENCE profiles_seq INCREMENT %s', (random() * 100)::int + 1);
RETURN 'Пользователь #' || nextval($1)::text;
END
$func$ LANGUAGE plpgsql SECURITY DEFINER;

create table profiles (
  id uuid not null,
  username text default nextval_rand('profiles_seq'::regclass),
  primary key (id)
);

insert into profiles (id) values
(gen_random_uuid()), 
(gen_random_uuid()),
(gen_random_uuid()),
(gen_random_uuid()),
(gen_random_uuid());

select * from profiles;

https://sqlize.online/sql/psql15/5c8c2073d52cd9696...