Навскидку. 1. order by замедляет выполнение запросов, требует памяти для сортировок, может еще и задействовать temp. Просто положите в таблицу отсортированные заранее данные - они всегда гарантированно будут возвращаться в таком же неизменном порядке. 2. Всегда старайтесь использовать select *, особенно в выражениях типа INSERT INTO ... SELECT * FROM ... Ведь порядок столбцов в таблицах и их количество никогда не меняется. 3. Если вам надо, например, изменить тип данных в столбце, то с этой задачей справится простой alter. Делать новый столбец, заполнять его корректными данными, потом менять местами со старым - это для ботаников. Лучше забокировать огромную таблицу и спокойно дождаться выполнения, а приложение подождет! 4. Туда же изменение большого количества данных. Делать пустую таблицу, заполнять измененными данными, потом удалять старую и подсовывать на ее место новую - это как-то слишком сложно. Помните: update всегда быстрее, чем insert! Заодно vacuum будет чем заняться. 4. Для продвинутых. Не доверяйте оптимизатору! Вы лучше знаете, где лучше индекс скан, а где фулл тейбл скан. Установите расширение для Postgres, которое добавляет хинты оптимизатора, пусть будет как в энтерпрайзном оракле! Пользуйтесь хинтами везде, где это возможно. Их много разных, попробуйте их все!
Кто же вас заставлял посмотреть доклад с таким названием? Докладов и статей с Best Practices хоть жопой ешь, да и подача там такая замечательная, что начитавшиеся их кодеры/dba считают себя бесповоротно просвещенными и в итоге начинают реализовывать слайды с этого доклада))
Крайне тяжело смотреть. Если бы вредные советы были рассказаны за 5 минут, а потом в нормальном повествовании они были разобраны, лекцию можно было бы досмотреть.
там все "вредные советы". но, очевидно, формат сарказма и вредных советов плохо подходит для того чтобы делиться опытом - мозг не любит напрягаться инвертировать смысл запомненного, даже если по факту все было правильно и хорошо расписано\рассказано
Человек выступающий за 80% времени использует сарказмы, тем самым не понимая что многие люди физически не способны воспринять сарказм... Самая лучшая практика выступать. (нет)
Что не так с orm? То что она работает медленнее чем голые оптимизированные запросы в бд? Давайте тогда писать на ассемблер. Причем лучше и СУБД под каждый набор данных будем создавать свою оптимизированную.
Мое любимое - не уверен что по теме но все же - не использовать никаких where в запросе, а тянуть всю таблицу в память приложения и там ее перебирать по условию
Навскидку.
1. order by замедляет выполнение запросов, требует памяти для сортировок, может еще и задействовать temp. Просто положите в таблицу отсортированные заранее данные - они всегда гарантированно будут возвращаться в таком же неизменном порядке.
2. Всегда старайтесь использовать select *, особенно в выражениях типа INSERT INTO ... SELECT * FROM ... Ведь порядок столбцов в таблицах и их количество никогда не меняется.
3. Если вам надо, например, изменить тип данных в столбце, то с этой задачей справится простой alter. Делать новый столбец, заполнять его корректными данными, потом менять местами со старым - это для ботаников. Лучше забокировать огромную таблицу и спокойно дождаться выполнения, а приложение подождет!
4. Туда же изменение большого количества данных. Делать пустую таблицу, заполнять измененными данными, потом удалять старую и подсовывать на ее место новую - это как-то слишком сложно. Помните: update всегда быстрее, чем insert! Заодно vacuum будет чем заняться.
4. Для продвинутых. Не доверяйте оптимизатору! Вы лучше знаете, где лучше индекс скан, а где фулл тейбл скан. Установите расширение для Postgres, которое добавляет хинты оптимизатора, пусть будет как в энтерпрайзном оракле! Пользуйтесь хинтами везде, где это возможно. Их много разных, попробуйте их все!
Хорошее чувство юмора. Сразу видно, человек любит свое дело.
сложно слушать. всё время приходится напоминать себе что это "worst practices"
согласен, сложно из-за этого воспринимать информацию
вредные советы в инженерии - худший вариант подачи, кто шарит - веселится, кто не шарит - ловит когнитивный диссонанс от переусложнения
Кто же вас заставлял посмотреть доклад с таким названием?
Докладов и статей с Best Practices хоть жопой ешь, да и подача там такая замечательная, что начитавшиеся их кодеры/dba считают себя бесповоротно просвещенными и в итоге начинают реализовывать слайды с этого доклада))
Это лучший доклад за всю историю HL!) Спасибо!)
Крайне тяжело смотреть. Если бы вредные советы были рассказаны за 5 минут, а потом в нормальном повествовании они были разобраны, лекцию можно было бы досмотреть.
Отлично! Хорошее настроение Илья мне сделал!
Так и не понял где тут правильные утверждения а где нет...
там все "вредные советы". но, очевидно, формат сарказма и вредных советов плохо подходит для того чтобы делиться опытом - мозг не любит напрягаться инвертировать смысл запомненного, даже если по факту все было правильно и хорошо расписано\рассказано
Человек выступающий за 80% времени использует сарказмы, тем самым не понимая что многие люди физически не способны воспринять сарказм... Самая лучшая практика выступать. (нет)
Хороший доклад! Не хватает закадрового смеха!
Отличный доклад !
Это прямо как Павел Воля, только лучше 😎😎😎
Что не так с orm? То что она работает медленнее чем голые оптимизированные запросы в бд?
Давайте тогда писать на ассемблер. Причем лучше и СУБД под каждый набор данных будем создавать свою оптимизированную.
вызывает когнитивный диссонанс - сколько смотрел, столько убеждал себя, что всё это неправда
Обалденно! Про PgPool2 - да-да-да!!!!, много на чём споткнулся, но научился готовить (хорош под конкретные кейсы)
Мое любимое - не уверен что по теме но все же - не использовать никаких where в запросе, а тянуть всю таблицу в память приложения и там ее перебирать по условию
На 8:15 привет ребятам из Битрикса.
Ха! Тоже про них вспомнил. Мне больше всего нравится, что они ОБЫЧНЫЕ таблицы называют highload ! Конечно, относительно их инфоблоков..
Отлично, улыбнулся, переслал разарабам
Вместо шуток можно было доказать и/или показать как лучше делать
Вот на моменте с вопросами из зала стало сложно понимать, где ирония, а где истина
не всегда понятно, что ирония, а что нет.
Сарказм выступающего никак не отличается от обычного повествования
Получается как в видео ua-cam.com/video/D6FDF2mxJAo/v-deo.html
Тяжело воспринимать, для профи видео.
Давно так не смеялся
Так я все делал правильно ))))
Совет 21 это +1