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