Это зависит от того, какая БД, каков размер полей, поток и разнообразие обращений, на каком железе всё крутится - в общем, от того, где именно узкие места. Схематично:

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

- Сервер посылает изменения в БД и второй раз напрасно грузит сеть.

- Если БД, например, Postgre, то она в любом случае, даже если пришёл один байт изменений, создаёт новую версию записи, копируя её целиком. То есть в этом месте разницы нет.

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

- В любом случае, кроме страниц данных, СУБД в том или ином виде пишет журнал изменений. И в этот журнал, скорее всего, лягут все пришедшие поля - хотя опять же зависит от СУБД. То есть, журналы изменений запросто начнут содержать 95% бессмысленной информации, пухнуть в 20 раз быстрее, требовать в 20 раз больше места и среди прочего грузить ввод-вывод, который имеет все шансы стать узким местом системы - и как следствие, обслуживать в 20 раз меньше клиентов на том же железе.

- С другой стороны, 2^n похожих запросов тоже могут доставить проблемы с кэшированием планов.

В общем - надо смотреть по конкретной ситуации. Абстрактно - в принципе лучше делать, но не факт, что в конкретном случае оно того стоит.