DK
и на выходе алиасы в 3 строки ненужные генерит)
Size: a a a
2021 January 29
SS
я вот также относительно недавно влетел в nest и typeorm. Не могу также понять какие же преимущества билдера, кроме недостатка, что нужно учить синтаксис)
Кол-во кода? Подсказки IDE? Скорость?)
D
я вот также относительно недавно влетел в nest и typeorm. Не могу также понять какие же преимущества билдера, кроме недостатка, что нужно учить синтаксис)
Привет! Ну серьёзно, возьмите и сделайте API фильтра чего-либо. Чтобы фильтров было штук 10-20, вариантов 5 сортировок и чтобы некоторые фильтры требовали join или подзапрос. Не на словах, а на деле посмотрите на этот код.
D
Тут можно долго спорить, но в реальности когда сталкиваешься с такой задачей, писать её на голом SQL неудобно. Да, можно, но этот код будет ужасен. Проверьте - убедитесь сами. А если начнёте рефакторить, сделаете самостоятельно квери-билдер.
SS
Тут можно долго спорить, но в реальности когда сталкиваешься с такой задачей, писать её на голом SQL неудобно. Да, можно, но этот код будет ужасен. Проверьте - убедитесь сами. А если начнёте рефакторить, сделаете самостоятельно квери-билдер.
Никто и не спорит, есть факты)
DK
Sergey Shumchenko
Кол-во кода? Подсказки IDE? Скорость?)
Нативный умно написан sql запрос будет быстрее работать чем запрос сделан с помощью билдера. Если вы про скорость написания, то да, на билдерах быстрее.
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
2021 January 30
D
Нативный умно написан sql запрос будет быстрее работать чем запрос сделан с помощью билдера. Если вы про скорость написания, то да, на билдерах быстрее.
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
"Нативный умно написан sql запрос будет быстрее работать чем запрос сделан с помощью билдера" - вообще-то нет.
D
Билдер просто формирует строку запроса путём вызова методов класса - и всё. Какой там проигрыш производительности? Ну несколько микросекунд, может быть. И то не факт.
И
Нативный умно написан sql запрос будет быстрее работать чем запрос сделан с помощью билдера. Если вы про скорость написания, то да, на билдерах быстрее.
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
Лучше написать sql-код в IDE для баз данных, и просто скопировать и добавить нужные параметры. Они наверное больше подскажут чем IDE для кода)
Зависит от
D
Если, конечно, даже потери в микросекундах критичны, то тут вместо NodeJS надо что-то другое посмотреть.
D
Но в веб такие лютые потери на сеть, что это смысла не имеет особого.
DK
"Нативный умно написан sql запрос будет быстрее работать чем запрос сделан с помощью билдера" - вообще-то нет.
Даже исходя с логики парсера ->
• SELECT first_name FROM user
• SELECT first_name first_first_name_name FROM user userUser
Первый нативный, второй билдер выдаст (может немножко короче), он не может быть быстрее первого
• SELECT first_name FROM user
• SELECT first_name first_first_name_name FROM user userUser
Первый нативный, второй билдер выдаст (может немножко короче), он не может быть быстрее первого
D
Даже исходя с логики парсера ->
• SELECT first_name FROM user
• SELECT first_name first_first_name_name FROM user userUser
Первый нативный, второй билдер выдаст (может немножко короче), он не может быть быстрее первого
• SELECT first_name FROM user
• SELECT first_name first_first_name_name FROM user userUser
Первый нативный, второй билдер выдаст (может немножко короче), он не может быть быстрее первого
Ну посмотри план запросов этих в БД. Возможно, удивишься, но он одинаков в обоих случаях
D
EXPLAIN ANALYZE SELECT ...
DK
Ну посмотри план запросов этих в БД. Возможно, удивишься, но он одинаков в обоих случаях
запрос на одну табличку с одним полем, а если будет нужно джоинить 12 таблиц, будет в 5 раз больше лететь по сети кода, чем нативно красиво оформлен)
D
запрос на одну табличку с одним полем, а если будет нужно джоинить 12 таблиц, будет в 5 раз больше лететь по сети кода, чем нативно красиво оформлен)
Ты считаешь, что длина строки с SQL-запросом на что-то оказывает хоть какое-то влияние? Это ж копейки, если у тебя, конечно, длина строки не в мегабайтах измеряется
D
Даже если у тебя запрос на пару мониторов по размеру, весит он до смешного мало.
D
Я ж говорю, если требования к производительности настолько высоки, то тут вообще NodeJS нет смысла юзать. Надо брать более производительные технологии.
E
@inpossibile Доброе утро, как и обещал, вот видео
JB
Доброе))