Телеграмм чат группы symfony

Size: a a a

symfony

2021 September 01

АС

Эмммм, то есть у тебя multi insert. Не проще ли через

INSERT INTO MyTable
  ( Column1, Column2, Column3 )
VALUES
  ('John', 123, 'Lloyds Office'), 
  ('Jane', 124, 'Lloyds Office'),

Сделать? В разы меньше запросов к базе будет.

источник

13:44пожаловаться #1

АВ

Алексей Велосипедкин... in symfony

Purge базы надо перед тестами делать

источник

13:44пожаловаться #2

КГ

Константин Грачев... in symfony

для его?

источник

13:45пожаловаться #3

КГ

Константин Грачев... in symfony

А если в конструкторе я ивент какой кидаю?

источник

13:45пожаловаться #4

Artem Molotov in symfony

Так это лишь один из примеров. Там может быть множество сущностей и куча операций БЛ. Это всё если на голые запросы переписать, то может получиться откровенное говнецо. Для редких мелких случаев — да, подойдет.

источник

13:46пожаловаться #5

АВ

Алексей Велосипедкин... in symfony

Может понадобится на супер нов орм перейти и абстракция в виде репозиторий нам поможет

источник

13:46пожаловаться #6

АС

Александр Семикашев... in symfony

Ну ведь это реально не разумно делать кучу Insert, банально в доках того же мускула написано "ребят так не надо так" и объясняется почему. При том насколько я помню после insert пересобираются индексы (смотря какие настройки).

источник

13:46пожаловаться #7

КГ

Константин Грачев... in symfony

ага, или фреймворк целиком поменять. Всё можно покрыть абстракциями, вопрос только в том что это не бесплатно. Если есть потребность и понимаешь цену флаг в руки и барабан на шею. Но в 99.9% случаев это нахер не нужно

источник

13:47пожаловаться #8

Artem Molotov in symfony

Так транзакция как раз таки от этого помогает. Куча инсертов + транзакция по скорости почти что как один инсерт. Об этом изначально и речь

источник

13:47пожаловаться #9

АС

Александр Семикашев... in symfony

У вас мускул?

источник

13:48пожаловаться #10

Artem Molotov in symfony

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

источник

13:49пожаловаться #11

Artem Molotov in symfony

Да хоть ПапаРимскийБД. Это не важно, т.к. стандарт SQL.

И да, мускул.

источник

13:49пожаловаться #12

Artem Molotov in symfony

@grachevko это тебе, случайно не туда тыкнул

источник

13:50пожаловаться #13

КГ

Константин Грачев... in symfony

Вспоминаем что программирование это про поиск компромиссов.
Если у тебя проблемы с производительностью тогда может и стоит задуматься о том чтобы выбросить ORM. Но текущий тред вроде про то как правильном ORM использовать, а не как бы его выкинуть)

источник

13:50пожаловаться #14

АС

Александр Семикашев... in symfony

Не совсем. Просто я как-то сталкивался ранее с подобным и до меня была подобная реализация. И мускул не хило напрягался, да в постргю было легче.

Но база в какой-то момент стала тяжело крутиться.

Хотя опять таки если у вас разовые операции... то окей

источник

13:50пожаловаться #15

АВ

Алексей Велосипедкин... in symfony

Uber с mysql на postgres переходил, и обратно. Все может быть.

источник

13:51пожаловаться #16

Artem Molotov in symfony

База в таком случае гнуться не будет. У вас проблема была в чем-то другом.

источник

13:51пожаловаться #17

КГ

Константин Грачев... in symfony

Я тоже с mysql на postgres переходил. Переписал код, поменял либы, исправил баги. И точно знаю что обратно на mysql не пойду, во всяком случае в ближайшей перспективе.

Ну и точно знаю, что пилить database agnostic code будет дороже чем тупо повторить тот же процесс в случае нового перехода

источник

13:52пожаловаться #18

КГ

Константин Грачев... in symfony

хз, я точно понимаю что мне это не нужно, поэтому даже не страдаю.

Агностик код актуален когда либу пишешь, чтобы расширить количество пользователей. А когда проект пилишь, там это нахер не нужно

источник

13:54пожаловаться #19

АС

Александр Семикашев... in symfony

Вроде верную ссылку даю: https://dev.mysql.com/doc/refman/8.0/en/optimizing-innodb-transaction-management.html

"InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database. When each change is followed by a commit (as with the default autocommit setting), the I/O throughput of the storage device puts a cap on the number of potential operations per second."

источник

13:54пожаловаться #20