Функции json конешн чутка посложнее чем простой SQL, зато работает очень быстро, быстрее чем всякими жабами и пайтонами.

Нет, я имею в виду SAVEPOINTs / exceptions. Но они тоже не сахар по производительности. А причём тут вообще JSON (я просто не совсем понял...)?

Да json не при чем, по сути. Просто много данных, которые надо батчем залить, да так чтобы транзакция целиком не откатывалась. Может имеет смысл savepoint/exceptions интервально и если вылетает ошибка - бинарным поиском до нее идти?

Функции json конешн чутка посложнее чем простой SQL, зато работает очень быстро, быстрее чем всякими жабами и пайтонами.

Там важно чтобы констрейшны на колонки сработали и не дали мусор залить.

Да json не при чем, по сути. Просто много данных, которые надо батчем залить, да так чтобы транзакция целиком не откатывалась. Может имеет смысл savepoint/exceptions интервально и если вылетает ошибка - бинарным поиском до нее идти?

А что у Вас там за CONSTRAINTs?

Ну, это если у тебя там прям действительно большеи объёмы. Если что поменьше то можно внешними скриптами на каком-нить пайтоне что-то наколхозить - это будет проще для восприятия.

А что у Вас там за CONSTRAINTs?

Да тот же FK, который предполагается, но его может не быть.

Может, их всё-таки возможно перевести в условия запроса, вроде: INSERT INTO your_table(...) SELECT ... FROM tmp_table WHERE <constraints>

Может, их всё-таки возможно перевести в условия запроса, вроде: INSERT INTO your_table(...) SELECT ... FROM tmp_table WHERE <constraints>

Хм, а это интересная идея, спасибо.

Там важно чтобы констрейшны на колонки сработали и не дали мусор залить.

Ну ты же не сразу в свою базу грузишь, а в промежуточную таблицу с json, а потом из неё тащишь уже в рабочу базу.

Ну ты же не сразу в свою базу грузишь, а в промежуточную таблицу с json, а потом из неё тащишь уже в рабочу базу.

Важна еще скорость. Скриптами тащить медленно. А вот залить в json и перетащить хранимкой то, что перетащится - интересная идея.

Важна еще скорость. Скриптами тащить медленно. А вот залить в json и перетащить хранимкой то, что перетащится - интересная идея.

Ну если прям аж так всё тяжело и объёмно то сделай кластер и на отдельном серваке делай.

Хм, а это интересная идея, спасибо.

Особо упорот^H^Hные могут попробовать генерировать этот WHERE автоматически, путём "вытаскивания" текущих constraints для данной таблицы из information_schema и т.п. ;)

Ну приходят в json, сейчас из них лепим sql для insert'а. Но рассматриваю все возможные варианты.

Да, вот ещё что: лучше "лепите" не INSERT-ы, а то, на чём Вы сможете использовать COPY — будет намного быстрее.

Важна еще скорость. Скриптами тащить медленно. А вот залить в json и перетащить хранимкой то, что перетащится - интересная идея.

(Подумав) А вообще, почему бы Вам сразу не использовать pgloader?

@karazbaev будет жить. Поприветствуем!

Да отфильтровали как могли. Но все равно в рандомных местах может падать, обмен с внешними системами. Вот и задался вопросом - умеет ли постгря стратегию "что-то лучше чем ничего". Т.е. залить то, что проверку проходит, а то что нет - проигнорить. Если под подавлением ошибок для каждой записи вы имеете в виду слать по одному Insert - то да, не порадовало. :(

Можно заюзать етл средство, например Hitachi vantara (pentaho), apache nifi. И в маппинге заливки разделить удачно залитые строки и те, что не залились, отложив их в отдельное место. Для того, чтобы заливалась хотя бы часть - устаноаите коммит интервал.

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

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

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

Павел будет жить. Поприветствуем!

Киса Мура будет жить. Поприветствуем!

привет народ

Ксения Великая будет жить. Поприветствуем!

идём

сиськи атакуэ!!

День добрый. Читаю документ по битемпоральным табличкам: https://hdombrovskaya.files.wordpress.com/2016/09/bi_temporal_pg_open_2016.pdf и там на 29й странице есть вот такое выражение: CONSTRAINT "bitemporal pk postgres_cluster_id " check(true or ’unique' <> '@postgres_port@') у меня 2 вопроса: 1) зачем check, который всегда проходит? true or ... что я тут не так понял? 2) что это за выражение: '@postgres_port@'? раньше не встречал такого. Как оно вообще работает, что тут за магия скрыта?

День добрый. Читаю документ по битемпоральным табличкам: https://hdombrovskaya.files.wordpress.com/2016/09/bi_temporal_pg_open_2016.pdf и там на 29й странице есть вот такое выражение: CONSTRAINT "bitemporal pk postgres_cluster_id " check(true or ’unique' <> '@postgres_port@') у меня 2 вопроса: 1) зачем check, который всегда проходит? true or ... что я тут не так понял? 2) что это за выражение: '@postgres_port@'? раньше не встречал такого. Как оно вообще работает, что тут за магия скрыта?

@postgres_port@ - никогда такого не видел

Возможно это некое выражение типа что ты должен сам вставить?

Понимаешь о чём, я @username@ ?

возможно...

тут даже ещё интереснее выражение: https://github.com/scalegenius/pg_bitemporal/blob/master/sql/metadata.sql#L206

тут даже ещё интереснее выражение: https://github.com/scalegenius/pg_bitemporal/blob/master/sql/metadata.sql#L206

С виду, все это extension, и специфические для него "навороты" (таблица constraints там тоже своя).

@etozheartemka будет жить. Поприветствуем!

Volodymyr Kopach будет жить. Поприветствуем!

@Vologdabobr будет жить. Поприветствуем!

подскажите плз у меня есть 2 модели Student и Group у них связи many_to_many т.е. студент может быть в нескольких группах и группы могут содержать нескольких студентов, в студенте специально для этого держу колонку group_ids - дык мне что то говорят мол так не делают и надо мол джоин таблицу делать, только я не очень понимаю смысл такого усложнения, действительно так делают или это все от лукавого?

подскажите плз у меня есть 2 модели Student и Group у них связи many_to_many т.е. студент может быть в нескольких группах и группы могут содержать нескольких студентов, в студенте специально для этого держу колонку group_ids - дык мне что то говорят мол так не делают и надо мол джоин таблицу делать, только я не очень понимаю смысл такого усложнения, действительно так делают или это все от лукавого?

Это называется "нормализация". Я бы Вам не советовал в реляционках что-то проектировать, пока Вы её не освоите, серьёзно.

Это называется "нормализация". Я бы Вам не советовал в реляционках что-то проектировать, пока Вы её не освоите, серьёзно.

дык что делать то? делать как говорят?

дык что делать то? делать как говорят?

Прочитать про нормализацию (copy-paste без понимания Вас тут до добра не доведёт). Но в этом случае да, делать отдельную таблицу для свзяи many-to-many. Например: "student_group".

Здравствуйте. Подскажите есть ли возможность внутри хранимки получить ее имя? Что-нибудь подобное rel_id для таблицы триггерной

Прочитать про нормализацию (copy-paste без понимания Вас тут до добра не доведёт). Но в этом случае да, делать отдельную таблицу для свзяи many-to-many. Например: "student_group".

будем делать, спасибо)

дык что делать то? делать как говорят?

Делай третью таблицу

Здравствуйте. Подскажите есть ли возможность внутри хранимки получить ее имя? Что-нибудь подобное rel_id для таблицы триггерной

См. https://stackoverflow.com/a/41889304

Чтобы не делать нормализацию - надо очень хорошо понимать почему ее в данном конкретном случае делать не надо

Во всех остальных случаях она нужна, имх

Чтобы не делать нормализацию - надо очень хорошо понимать почему ее в данном конкретном случае делать не надо

блин чет у нас в проекте ни одной джоин таблицы до сего дня было, как мы жили у нас 150 моделей

блин чет у нас в проекте ни одной джоин таблицы до сего дня было, как мы жили у нас 150 моделей

Судя по отсутствию запятых - не особо хорошо ??

Судя по отсутствию запятых - не особо хорошо ??

ну и что мне теперь их пихать везде?

видимо придется

Спасибо за информацию. Не додумался искать по английски

См. https://stackoverflow.com/a/41889304

Прочитать про нормализацию (copy-paste без понимания Вас тут до добра не доведёт). Но в этом случае да, делать отдельную таблицу для свзяи many-to-many. Например: "student_group".

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

Для слабоструктурированных данных или аттрибутов, очевидно

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

Эээ... а почему Вы думате, что JSON/hstore придумали в реляционках? А ввели их, по хорошему, примерно затем же, зачем и array — хранить структурированные типы, из которых можно что-то достать, проверить и т.п.

Читаю про нормализацию, дык зачем тогда придумали эти hstore и jsonb- это же противоречит нормализации, такой формат главно что в него что угодно засунуть можно, там нормализацией и не пахнет даже

Для hstore и json-а можно ввести понятие не нормальной формы: первая не нормальная форма, вторая... :)

Но вообще если бы у меня в команде кто-нибудь задумал хранить многие-ко-многим не через табличку связей - то сначала он бы объяснил свое решение

Мы для крайне ограниченных наборов используем иногда битовые маски

Но вообще если бы у меня в команде кто-нибудь задумал хранить многие-ко-многим не через табличку связей - то сначала он бы объяснил свое решение

Ну вот теория реляционных СУБД в целом, и нормализации в частности и есть объяснение такого решения. :)

Ну вот теория реляционных СУБД в целом, и нормализации в частности и есть объяснение такого решения. :)

В смысле - почему нормализовать плохо?)

В смысле - почему нормализовать плохо?)

Нормализовать — хорошо. Не нормализовать — плохо.

Почти всегда так, согласен

Почти всегда так, согласен

По-хорошему, вообще всегда так для OLTP. В DWH, конечно, можно лепить всяческие извращения. ;)

блин чет у нас в проекте ни одной джоин таблицы до сего дня было, как мы жили у нас 150 моделей

слово "модель" намекает, что у вас orm?

слово "модель" намекает, что у вас orm?

да, видимо она самая

По-хорошему, вообще всегда так для OLTP. В DWH, конечно, можно лепить всяческие извращения. ;)

Ненативные (не fdw) шарды и хайлоад. Там бывают детали с нормальными формами... Да и с хранением данных вообще :)

слово "модель" намекает, что у вас orm?

ну, т.е. у нас есть модель студента и все его атрибуты обьектов класса Студент являются колонками в таблице студент

а эти Студенты что-нибудь делают? ну, в классы собираются, на занятия ходят, книжки получают?

Ненативные (не fdw) шарды и хайлоад. Там бывают детали с нормальными формами... Да и с хранением данных вообще :)

Там уже, скорее всего, данные не очень-то консистентны. И это не только мой личный опыт, исследования реальных ненормализованных баз данных намекают на то, что если есть возможность в базу внести какой-то мусор, он там с немалой вероятностью появится. :(

а эти Студенты что-нибудь делают? ну, в классы собираются, на занятия ходят, книжки получают?

да да да, все по полной

да да да, все по полной

а как вы их к классам привязываете?

Там уже, скорее всего, данные не очень-то консистентны. И это не только мой личный опыт, исследования реальных ненормализованных баз данных намекают на то, что если есть возможность в базу внести какой-то мусор, он там с немалой вероятностью появится. :(

Да, это уже много много вопросов с консистентностью, все верно

а как вы их к классам привязываете?

раньше у студента было по 1 классу - связь была has_one и в студенте хранился group_id а сейчас надо ко многим сделать

Орм - зло. Люди делают херню не понимая сути СУБД и это жопа полная. Верно сказано выше, что должна быть третья таблица, которая объединит сущности студентов и групп. А типы данных навроде json в том же постгри больше нужны не для хранения данных, а для обмена данными в веб-разработках.

Про битовые маски тоже верно сказано, мы тоже используем. Это элегантное решение, позволяющее ещё и компактные базы делать

Орм - зло. Люди делают херню не понимая сути СУБД и это жопа полная. Верно сказано выше, что должна быть третья таблица, которая объединит сущности студентов и групп. А типы данных навроде json в том же постгри больше нужны не для хранения данных, а для обмена данными в веб-разработках.

И автомобиль, и компьютер - всё это от Сатаны. Если человек лезет в ORM, не понимая основ, то проблема не в ORM.

Орм как раз придуман для того, чтобы якобы проще делать без особого понимания + лёгкая переносимость между субд

А работать с СУБД не зная основ...

Я полагал всегда, что ORM в мире БД подобно фреймворкам в мире ЯП: облегчает рутину и решает некоторые проблемы безопасности. Но никак не решает проблему понимания

пора уже заводить какой-то бложек "разрабы тупые"

ebanoe it есть :D

ebanoe it есть :D

Где? ))