Комментарии 4
А не проще создать временную таблицу с результатами в MySQL а потом запустить два запроса — один на delete а второй на upsert. Тогда по сети данные нужно будет гонять только один раз и вся логика будет в одном месте в этих двух SQLях.
Да, действительно можно и так, и в скорости мы получим выйгрыш однозначно, правда тогда я не очень представляю, как в таком случае можно реализовать логику сохранения порядка следования строк как в новом массиве (без заведения соответствующего ключа). То есть например, когда мы просто меням местами две строчки, при этом значения всех полей остаются как есть.
И второй момент, в форме вывода надо будет отслеживать ключи БД, которые могут быть нарушены пользователем. Например, когда он случайно удалит строку, и потом не сохраняя документ вновь ее добавит с теми же значениями, в результате мы потеряем ключ БД этой строки, и он будет изменен после сохранения, что не есть хорошо в некоторых случаях. Ну и дополнительная логика в обработке формы появляется.
И второй момент, в форме вывода надо будет отслеживать ключи БД, которые могут быть нарушены пользователем. Например, когда он случайно удалит строку, и потом не сохраняя документ вновь ее добавит с теми же значениями, в результате мы потеряем ключ БД этой строки, и он будет изменен после сохранения, что не есть хорошо в некоторых случаях. Ну и дополнительная логика в обработке формы появляется.
По первому пункту, я считаю, что добавления номера строки только на пользу пойдет, так как порядок строк будет сохранен в явном виде.
По второму — тоже — ну и что строка будет удалена и потом снова создана?
А если это частый use-case, то надо просто undelete в gui добавить и показывать ту же строку, как она была сначала считана из базы.
Иногда возможно лучше логику в коде держать, но где-то я слышал такую максиму, что все, что можно сделать в SQL, надо делать в SQL. По крайней мере чтобы не изобретать велосипед, не терять время на сетевые операции и облегчать масштабирование.
По второму — тоже — ну и что строка будет удалена и потом снова создана?
А если это частый use-case, то надо просто undelete в gui добавить и показывать ту же строку, как она была сначала считана из базы.
Иногда возможно лучше логику в коде держать, но где-то я слышал такую максиму, что все, что можно сделать в SQL, надо делать в SQL. По крайней мере чтобы не изобретать велосипед, не терять время на сетевые операции и облегчать масштабирование.
В моем частном случае этот код работает в составе CMS, в которой все делается максимально модульно и гибко. И в дальнейшем при замене в каких то определенных случаях самой БД, например, на Nosql или любую другую, проблем по адаптации будет намного меньше, по этому лично для этого проекта он подходит больше. Ваш вариант тоже очень интересный, так как тут помимо скорости можно выйграть в более простой реализации. Если кто-то захочет воспользоваться данными методами у него всегда будет выбор.
Абсолютно согласен и с тем, что максимум надо делать в SQL, особенно когда application работает на скриптовых языках, которые по определению в десятки раз медленнее, плюс экономия на коммуникациях с базой.
Абсолютно согласен и с тем, что максимум надо делать в SQL, особенно когда application работает на скриптовых языках, которые по определению в десятки раз медленнее, плюс экономия на коммуникациях с базой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Модификация в БД табличных или множественных полей документов