Work.Дыбр

[dzz]

Бывает, что в суете бегущих дней никто не реализовал простую, вроде бы, штуку, и нет ответа на твой вопрос ни в StackOverflow, ни в гугле... :)

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

А я не нашёл ничего лучшего, чем соорудить простенькую функцию на Pl/PgSQL. Бонус - она исполняется на стороне сервера и может быть задействована в любом запросе или хранимой функции/процедуре без запуска дополнительных сущностей.

Выглядит так:

-- random_mac() - generate random mac address with the first octet '00'

create or replace function random_mac()
returns text as $$
declare 
    line text;
    bit text;
    cnt integer;
begin
    line = '00';
    for cnt in 1..5 loop 
        bit = to_hex(floor(random()*255)::int);
        if length(bit) = 1 then 
            bit = '0'||bit; 
        end if;
        line = line || ':' || bit;
    end loop;
    return line;
end;

$$ language plpgsql;

-- Create table for urandom_mac() if not exists

create table if not exists random_mac_t (mac text primary key);

-- urandom_mac() - generate unique random mac address 

create or replace function urandom_mac()
returns text as $$
declare 
    line text;
    cnt integer;
begin
    cnt = 1;
    while cnt > 0 loop
        line = random_mac();
        select count(mac) from random_mac_t into cnt where mac = line;
    end loop;
    insert into random_mac_t (mac) values (line);
    return line;
end;

$$ language plpgsql;

-- Usage:

insert into device_t (id, mac, ...) values (new_id(), urandom_mac(),...);

-- The end --

Возможно, кому-то пригодится.

P.S. Постояно замечаю, что люди используют СУБД преимущественно как место хранения таблиц, вынося всю логику в приложения. Причём, началось это не вчера (ругался на такой подход ещё в нулевые), но в последние годы тенденция приобрела угрожающие масштабы, вплоть до попыток теоретического обоснования "почему центральная БД с логикой - это плохо" со стороны микросервисников.

Джеффри Ульмана на них нет :)))

Comments

[motherware.livejournal.com]

Помилуйте, такой подход хорош только на маленьких проектах

[dzz.livejournal.com]

Подход с центральной СУБД? Думаю, моя практика (несколько внедрений больших биллингов, CRM и аналитических систем в национальных операторах связи и авиации) показывает обратное :)

На самом деле, "каждому овощу — свой фрукт". Микросервисная архитектура с тучей мелких БД, согласованных только по API, позволяет гибко менять интерфейсную часть системы, но весьма уязвима к размыванию общей модели данных и несёт с собой массу накладных расходов. Где-то это приемлемо, где-то — нет.

Ну и аналогичная гибкость неплохо достигается другими архитектурными средствами (например, применением интеграционных платформ). Что до СУБД, то у меня стойкое впечатление, что вчерашние выпускники университетов (aka молодые эффективные программисты) просто не умеют их готовить :)

[motherware.livejournal.com]

Ну с последним спорить не приходится вообще