Типичные ошибки при разработке приложений, работащих с PostgreSQL / Иван Фролков
Вставка
- Опубліковано 26 кві 2020
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
Saint HighLoad++ 2019
Тезисы и презентация:
www.highload.ru/spb/2019/abst...
По роду деятельности мне регулярно приходится иметь дело с приложениями, использующими PostgreSQL, и некоторые проблемы встречаются достаточно регулярно. Об этих проблемах, о том, как их избежать и расскажет этот доклад.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Зря докладчик упомянул timestamp (или rowversion) тип ms sql в ключе ненужности и заменимости хэшем, он явно не вникал в суть этого типа. Дело в том, что значение колонки rowversion обновляется при любой операции update, даже той, которая не меняла данные, в отличие от простого хэша. В некоторых случаях эта особеность используется бизнес логикой приложения.
Хороший доклад, спасибо! 49:00 - чистый SQL удобней в чём? Есть у меня эндпоинт, где куча опциональных фильтров и сортировок - разве выборку для него удобно делать на чистом SQL? Это ж лапша из кода для конкатенации строки запроса, подверженная уйме ошибок. ORM/QueryBuilder даёт более читабельный код и повышает вероятность того, что запрос будет корректным. Вообще не представляю, как можно, не изобретая собственный QueryBuilder, сделать эту задачу с помощью конкатенации строки и при этом чтобы код проекта не превратить в помойку. Если кто знает, то скиньте, пожалуйста, ссылку на Гитхаб - было бы очень интересно посмотреть.
SQL конечно удобней, это же язык запросов специально разработанный для работы реляционной моделью данных. С ОРМ вы будете варить масло масляное, и ав какой-то момент, spoiler: очень быстро уткнетесь в его ограничения, из которых простого выхода не будет.
@@awsom82 по-моему, вы проигнорировали кучу аргументов из моего предыдущего комментария. А что касается "из которых простого выхода не будет" - это какие, например? Даже при использовании ORM, никто не мешает использовать для конкретных запросов чистый SQL, либо его фрагменты. Одно никак не мешает другому.
Анализ решения timestamp в MSSQL раскрыл мне глаза, что спикер совсем не анализирует чужие точки зрения. Есть вот postgres, худо бедно работающий бесплатно со всеми минусами и всё. Люди просто живут с ним и работают, почему другие кампании принимают какие-то решения? кажется это даже им не интересно попытаться понять. Они всё измеряют в рамках postgres'а. В общем у меня вопрос к уровню профессионализма в общем развитии к спикеру. Слишком однобоко всё.
товарищ просто не знает про столбец xmin и на ходу придумывает велосипед
Согласен, идеи, которыми руководствовались при введении типа timestamp/rowversion гораздо глубже и никак не связаны с хэшем. Иногда полезно знать, что обновление строки производилось, даже если в ней не поменялся ни один байт информации. Докладчик просто не сталкивался с решениями на базе этого типа.
PostgreS профессионал???
? postgre и postgres -- оба написания верны
@@awsom82 у вас есть ссылка на произношение у нативных специалистов - спикеров с S в конце?
Вот опять докопались
Ну такой сленг в среде. Так привыкли. Есть много вещей важнее произношения
Какой к черту сленг?? БД до последнего переименования называлась Postgres, а PostgreSQL сократили чтоб не дублировать sS!
Вы что в консоль не заходили ни разу?! Там от дефолтной базы до дефолтного пользователя всё postgres... откуда эта постгря в голове возникла?!
@@awsom82Нет, не верны. Либо Postgres, либо PostgreSQL.
очень странный доклад, не со всем могу согласиться после работы с ддд. Слышу сплошное нарушение инкапсуляции, размазывание бизнес логики. И всё это что бы быстро работало.
докладчик набил руку на здоровенных монолитах... посочувствуем ему)
У автора между строк сквозит пассивной агрессией ко всему и вся. Душно, откройте форточку, пожалуйста