@Komzpa есть совет?

Ты вроде как разные грани постгриса смотрел

Ну так может libpostal? Чтобы нормализовать адрес а не хранить варианты написания.

Или вообще геокодер как отдельную сущность. Чтобы по названию выдал place id.

Челб-ск, Курч. р-н, ул-ца Автодрожная

libpostal нормализует?

г. Небережные Челны содержит кроме улиц еще и локальное деление - Комплекса (как видно в примере)

Мне нужно по сути не только принять и валидировать, но и при наличии нового варианта ввода - хранить его для защиты от дурака

При всем при этом - только 1 вариант верный

Можно натренировать. Там машинное обучение есть. Возможно из коробки именно для Челнов нет.

Г. Москва м. Ново-кая. Какой ответ правильный?

Я не устанавливал, пытаюсь оценить необходимоть развертки через онлайн инструменты.

Судя по всему это библиотека для нормализации почтовых адресов. Тект должен быть полным походу

По умолчанию mapbox гоняет на США. Русскую схему надо шаманить.

У тебя она есть развернутая?

Нет

Есть хотя бы онлайн пример испольования этой библиотеки с русской адресной базой?

OSM Например такое не жрет

Ну судя по документации postgres - они Тоже за таблицу один ко многим F.31.5

Получается что это самое простое решение. Хотя и не радуют меня лишние таблицы в БД

чтоб скормить sql dump в pgloader, нужно оставить в дампе только сами строки данных, вырезав все комманды оттуда, и указать тип LOAD COPY?

а ок, ему можно любое мясо скармливать, он все равно отбрасывает невалидные строки. Замечательная утилита, столько времени сэкономила

Может это норм и не надо стараться улучшать код и выносить его полностью в pg

У кого какое мнение?

Я сопровождаю постгрес с 3к pl/sql процедур. Вся логика в базе.

Не надо так.

Это невозможно профилировать, это сложно поддерживать, это пздц мигрировать (а у меня 9.0)

(На самом делн профилировать тоже можно, но в основном силами прогеров)

Не надо так.

postgres=# select count(*) from pg_proc; count ------- 10327

Моё личное мнение - база должна быть базой. Без серьёзной необходимости (например, много данных приходится гонять и проще их обработать внутри базы) НЕ НУЖНО пихать логику в базу

И да, не запихивайте файлы в базу "патамушта так проще"

Тоже при крайней необходимости

А то в нагрузку к первой базе есть отддельная (первая база лезет через sql в другую) на полтора терабайта.

Разъехалась реплика + медленные диски = хер знает как это чинить.

все, что вы написали - это все сомнительно (точнее спорно), надеюсь не ради холивара

Наболело

А что сомнительно?

все

Давайте по пунктам, что ли?

нет, в другой раз, работать надо

Это правда моё личное мнение и особо обсудить его было не с кем

Нуок

нет, в другой раз, работать надо

Жаль, я бы хотел послушать почему это ок

Моё личное мнение - база должна быть базой. Без серьёзной необходимости (например, много данных приходится гонять и проще их обработать внутри базы) НЕ НУЖНО пихать логику в базу

Ну норм так утверждения. ? Только вот непонятно - как бы ты предложил этот код на sql реализовать. Процедурой?

А если таблиц 8-9 с дочерними таблицами variants. Но родителькие содержат разное количество столбцов? В процедуре жестко задаются возвращаемые столбцы (RETURNS TABLE() ) и этот пипец ёмко будет каждый раз перечитывать дропать и апдейтить процедуру при изменении структуры таблицы

Я поэтому код и выложил. До этого 2 часа пробовал либо с JOIN либо процедурой Всё это получается слишком емко и дорого с точки зрения обслуживания

Пришел к выводу что это самый оптимальный вариант. Тем не менее это субъективное мнение. И это осознаю. Именно по этой причине я задаю вопрос и ссмотрю с любой стороны. @vanadium23 твое мнение имеет место быть. Но скинь свое решение. Чтобы как-то на примере

все, что вы написали - это все сомнительно (точнее спорно), надеюсь не ради холивара

а я с ним 100% согласен... не говоря о том что pl/pgsql в постгресе через жопу сделан и давно требует переписки

Антипаттерн "золотой молоток" говорит о том, что нельзя применять одно и тоже средство для всех подходов.

Пришел к выводу что это самый оптимальный вариант. Тем не менее это субъективное мнение. И это осознаю. Именно по этой причине я задаю вопрос и ссмотрю с любой стороны. @vanadium23 твое мнение имеет место быть. Но скинь свое решение. Чтобы как-то на примере

я видимо вклинился не в тот момент. О каком решение идёт речь? Я просто увидел утверждение, что писать кучу процедур - это плохо, на которое возразили. Хочу понять, когда писать много процедур - это хорошо

это не патерн это называется, думать головой надо

С этого началось

я видимо вклинился не в тот момент. О каком решение идёт речь? Я просто увидел утверждение, что писать кучу процедур - это плохо, на которое возразили. Хочу понять, когда писать много процедур - это хорошо

никогда, и особенно в postgres

это не патерн это называется, думать головой надо

Антипаттерн. Есть такое понятие. ? По сути спиок частых ошибок разработчиков и управленцев

если можно обойтись без процедуры (т.е. скорость не просядет и тебе пол бд доставать не нужно) то нужно обойтись

если можно обойтись без процедуры (т.е. скорость не просядет и тебе пол бд доставать не нужно) то нужно обойтись

На скриншоте в принципе вся логика описана.

Антипаттерн. Есть такое понятие. ? По сути спиок частых ошибок разработчиков и управленцев

да знаю я эти понятия... только часто они ошибочны

Это интересно. Например?

Я готов слушать и слышать

ERROR: S client not available

С этого началось

надо что то делать с 100 интегерами? Это лучше в приложении.

Ну как бы array_unique и чтобы порядок остался

В postgres Это DISTINCT

Но он в купе с order Не работает

в смысле не работает?

select distinct on ()

кто на конференции? на какой следующий доклад идёте и почему?

коллеги подскажите момент по чистке таблиц

таблицу чищу а место на винте не освобождается

блоб отданный таблице будет дальше им и пользоваться

только после vacuum full место освобождается

ЕМНИП

PG_repack посмотри

спс ща смотрю

select distinct on ()

[42P10] ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list

никогда, и особенно в postgres

Я тут мал-мала кой над чем поиздевался, и у меня кастомный скрипт с функицей оказался ощутимо быстрее, чем с прямой вставкой. Так что - спорное утверждение. Весьма спорное.

Я тут мал-мала кой над чем поиздевался, и у меня кастомный скрипт с функицей оказался ощутимо быстрее, чем с прямой вставкой. Так что - спорное утверждение. Весьма спорное.

дык блин никто не говорит что по IO это всё быстрее, тут другие причины это не использовать, больше архитектурные

кто на конференции? на какой следующий доклад идёте и почему?

а я не пошёл... я купил мотыля и поехал на реку, сядешь на берегу... (С) S.P.O.R.T.

Юр, на какую реку ты поехал? Не на Пехорку случаем?

подскажите в 9.4 автовакуум по дефолту включен или выключен?

подскажите в 9.4 автовакуум по дефолту включен или выключен?

он вроде всегда был включен по умолчанию :) это как бы такая важная часть БД

хмм почему же место не освобождается

а оно и не должно :)

место освобождает vacuum full

авто вакуум немного другими делами занимается (в редких случаях вроде может немного уменьшить с конца место, но на практике этого не происходит)

Юр, на какую реку ты поехал? Не на Пехорку случаем?

на Shibuya... правда рыбы я там не поймаю

что-то странное увидел