Size: a a a

pgsql – PostgreSQL

2020 May 20

YS

Yaroslav Schekin in pgsql – PostgreSQL
sexst
А по существу?
Это и есть всё "существо", то-то и оно.
Т.е. покажите мне (или комитету ISO SQL) хоть один случай, когда следование формальной процедуре нормализации приводит к таким "потребностям".
И, кстати, в ISO SQL есть ASSERTIONS (это как CHECKs, только для всей БД, а не "внутри" записи) для "сложных" случаев... только реализовал их примерно никто. :(
источник

s

sexst in pgsql – PostgreSQL
Victor Yegorov
> Но много. Instead of триггеры на view для обратной совместимости, на каждую табличку по пачке для перекидывания при изменении статуса
поясните тогда откуда это всё, если связь только одна? на одну связь один триггер достаточно, можно одной ф-цией обойтись для ряда таблиц (это на вырост)
Как обойтись одной то? На одной таблице нужно проверять чтобы в неё не вставляли то, что запрещено. На другой проверять чтобы не меняли то, что нельзя. Уже две функции и несколько триггеров.
источник

s

sexst in pgsql – PostgreSQL
Yaroslav Schekin
Это и есть всё "существо", то-то и оно.
Т.е. покажите мне (или комитету ISO SQL) хоть один случай, когда следование формальной процедуре нормализации приводит к таким "потребностям".
И, кстати, в ISO SQL есть ASSERTIONS (это как CHECKs, только для всей БД, а не "внутри" записи) для "сложных" случаев... только реализовал их примерно никто. :(
Ну, кстати, да, как вариант. Но мне такое видится в реализации ещё более накладным решением по потребляемым ресурсам.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
sexst
А по существу?
Я вот прочитал Ваш пример, кстати:

> Опять же другая таблица, а не поле с флагом в первой, по сторонним причинам, так нужно.

Так вот, "так нужно" аргументом в проектировании схемы БД не является. ;)
Т.е. почему кто-то должен создавать features для поддержки того, что считается "кривыми" моделями?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
sexst
Ну, кстати, да, как вариант. Но мне такое видится в реализации ещё более накладным решением по потребляемым ресурсам.
Я не спорю, что иногда "правильного" решения либо нет, либо оно по каким-то причинам хуже... только это бывает слишком редко, чтобы этим заморачиваться (т.е. у разработчиков СУБД сразу возникают вопросы вроде "кому это нужно?" и т.п.).
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
sexst
Ну, кстати, да, как вариант. Но мне такое видится в реализации ещё более накладным решением по потребляемым ресурсам.
Вот, например, можно построить стандартную (реляционную) модель для хранения тегов для каких-то объектов в БД.
Тем не менее, многие пишут, что, не считая контроля целостности, использование типов массивов для этого в PostgreSQL удобнее и даже производительнее. Далее, кто-то даже разрабатывал patch, чтобы решить эту проблему с целостностью — возможность добавления Foreign Keys на другую таблицу (со списком тегов, в этом примере) для элементов массива (но он как-то "застрял", насколько я помню).
источник

s

sexst in pgsql – PostgreSQL
Yaroslav Schekin
Я вот прочитал Ваш пример, кстати:

> Опять же другая таблица, а не поле с флагом в первой, по сторонним причинам, так нужно.

Так вот, "так нужно" аргументом в проектировании схемы БД не является. ;)
Т.е. почему кто-то должен создавать features для поддержки того, что считается "кривыми" моделями?
Просто вторая табличка это одна из кучи таблиц в отдельной schema, хранящих конфигураци. сервиса пользователя (и там дофига всяких вещей). Причём применение конфигурации сделано по транзакцирнному принципу - пользователь делает какие-то отдельные изменения в куче разных сервисов и параметров по api, они в соответствующие таблички пишутся  в копию активной конфигурации, но с новым id конфигурации. Накопленные изменения можно потом одной кнопкой применить (физически в таблице с id конфигураций старая помечается, исторической, а новая с изменениями помечается активной, после чего оно на сервис накатывается). Ну или можно rollback сделать, тогда просто по номеру транзакции всё грохается разом. Или какую-то старую конфигурации посмотреть/накатить.

А первая табличка - это просто справочник по возможным вариантам одного из параметров.

Я вот честно хз как такую систему можно сделать удобнее.
источник

s

sexst in pgsql – PostgreSQL
Yaroslav Schekin
Вот, например, можно построить стандартную (реляционную) модель для хранения тегов для каких-то объектов в БД.
Тем не менее, многие пишут, что, не считая контроля целостности, использование типов массивов для этого в PostgreSQL удобнее и даже производительнее. Далее, кто-то даже разрабатывал patch, чтобы решить эту проблему с целостностью — возможность добавления Foreign Keys на другую таблицу (со списком тегов, в этом примере) для элементов массива (но он как-то "застрял", насколько я помню).
Не, ну это уже бред, согласен.
источник

МШ

Михаил Шурутов... in pgsql – PostgreSQL
targitaj
им хочется в докере потому что "деплоить просто"
Разрабы рулят эксплуататорами? Оне упоролись на отличненько.
источник

2_

2flower _ in pgsql – PostgreSQL
sexst
Не, ну это уже бред, согласен.
почему? Я один из тех, которому как раз казалось, что массив из тэгов, особенно если их 0..3, очень  даже интересная идея в плане производительности.
источник

W

WoodyFire in pgsql – PostgreSQL
Всем доброго дня.
Ребят помогите пожалуйста. Всю голову себе уже сломал. Букварь конечно рядом, но не достаточно к сожалению. Нужно вывести результат запроса из функции. Проблем в этом нет. Но есть НО. Запрос динамический причем меняется наименование таблицы. С подстановкой значений проблем нет.
Вот собственно код:
https://pastebin.com/zpYbE2zU

Ошибку выдает следующую:
https://pastebin.com/K7Ggtg7G

Предполагаю, что я не правильно пытаюсь передать результат выполнения запроса из функции. Но вот как правильно написать понять не могу. За ранее спасибо.
источник

W

WoodyFire in pgsql – PostgreSQL
Я победил. 😎 Ну наконец-то
источник

W

WoodyFire in pgsql – PostgreSQL
источник

W

WoodyFire in pgsql – PostgreSQL
Надо было Вам раньше написать. 3 минуты и проблема решена. А я голову ломал пару дней (
источник

AM

Almas Maratov in pgsql – PostgreSQL
Привет всем.
Я хотел спросить, как при pg_dump указывать путь сохранения файла?
Я использовал команду pg_dump database > C:\pgbackup\database.sql но мне выдается ошибка что неправильная команда \pgbackup.
я использовал разные варианты и с флагами и с таром но все равно не выходит. Всегда одна и та же ошибка. Если не указывать путь а просто написать название sql файла то все вроде делается без ошибок но тогда я не знаю как мне достать этот файл.
Буду благодарен любому ответу. Спасибо)
источник

П

Павел in pgsql – PostgreSQL
Almas Maratov
Привет всем.
Я хотел спросить, как при pg_dump указывать путь сохранения файла?
Я использовал команду pg_dump database > C:\pgbackup\database.sql но мне выдается ошибка что неправильная команда \pgbackup.
я использовал разные варианты и с флагами и с таром но все равно не выходит. Всегда одна и та же ошибка. Если не указывать путь а просто написать название sql файла то все вроде делается без ошибок но тогда я не знаю как мне достать этот файл.
Буду благодарен любому ответу. Спасибо)
а если слеши наоборот? c:/folder/folder  ?
источник

РЖ

Роман Жарков... in pgsql – PostgreSQL
А если путь до файла в кавычки взять?
источник

AM

Almas Maratov in pgsql – PostgreSQL
Павел
а если слеши наоборот? c:/folder/folder  ?
о команда прошла без ошибок
источник

AM

Almas Maratov in pgsql – PostgreSQL
блин но че то в папке не появилось)
источник

AM

Almas Maratov in pgsql – PostgreSQL
это делается моментально?
источник