Почему лишние пробелы и переносы строк в запросах плохие?

Question

Время от времени я вижу, что люди говорят, что SQL-запрос, отправляемый на сервер из клиентского приложения, не должен содержать лишних разрывов или пробелов. Одна из причин, которую я услышал, это «зачем тратить сетевой трафик?».

Есть ли реальная причина усложнять чтение и редактирование кода в пользу удаления всех пробелов?

С пробелами:

$q = 'SELECT
            `po`.*,
            `u`.`nickname`,
            `u`.`login`
        FROM
            `postponed_operations` AS `po`
            LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id`
        ORDER BY `will_be_deleted_after`';
return mysql_query($q);

без пробелов:

$q = 'SELECT '.
            '`po`.*,'.
            '`u`.`nickname`,'.
            '`u`.`login`'.
        'FROM '.
            '`postponed_operations` AS `po` '.
            'LEFT JOIN `users` AS `u` ON `u`.`id`=`po`.`user_id` '.
        'ORDER BY `will_be_deleted_after`';
return mysql_query($q);

Answer 1

Правда, это будет стоить сетевого трафика и времени сервера;но это будет незначительным во всех, кроме самых крайних случаев.Теперь, если вы редактируете код FaceBook (или Google, или подобного) и оптимизируете таким образом 10 самых распространенных запросов, то есть смысл, поскольку они будут выполняться миллиарды раз в день.Но во всех остальных случаях я думаю, что стоит подумать об удалении пробелов.

Answer 2

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

Answer 3

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

Если бы мы говорили о сети, я бы сказал, что дополнительные затраты на выполнение могут потенциально стоить того для статического контента (редко используемые файлы сценариев и тому подобное), ноЯ бы скептически отнесся к этому для динамического контента.

Во всех случаях:

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

Возможно, не относится к вашему случаю, ноЯ все равно упомяну об этом: совершенно другой подход может заключаться в том, чтобы использовать плотно упакованный формат сообщения вместо идентификатора запроса, вместо того, чтобы каждый раз передавать запрос.

Answer 4

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

Скорее, вам следует беспокоиться о удобочитаемостии ремонтопригодность кода.Это две очень важные вещи, которые вы должны иметь в виду при написании программного кода!

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

Например.Вы можете изменить следующий запрос

SELECT
            `po`.*,
            `u`.`nickname`,
            `u`.`login`
        FROM
            `postponed_operations` AS `po`
            LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id`
        ORDER BY `will_be_deleted_after`;

на

CALL GetLoginData();

Теперь это будет сокращение ~ 80-95%.Но стоит ли это того?

Определенно нет.

Подобные поступки скорее сделают жизнь разработчиков несчастной, не прибавляя к этому никакого значительного значения!

При этом используйте уменьшенную версию кода только в тех местах, где никто не будет изменять код.Например,Библиотеки CSS и библиотеки JS, которые вы никогда не измените!

Надеюсь, вы поняли, и вы продолжите писать читаемый и поддерживаемый код!

Answer 5

Абсолютно. Я делаю это все время. Я также:

• удалить кавычки. Кому они нужны?

Следовательно,

`po` ----- becomes -----> po 

• использовать как можно меньше имен для баз данных, таблиц, полей, индексов и т. Д.

Таким образом,

postponed_operations  --- becomes ---> po    --- p is already taken for posts
will_be_deleted_after --- becomes ---> wi    --- w is already taken for words

• Полностью удалите ненужные ключевые слова, такие как AS. Все имена таблиц в любом случае короткие (правило 2!)

* * Тысяча двадцать-одина Поэтому * * тысяча двадцать-дв

LEFT JOIN `users` AS `u`  --- becomes --->   LEFT JOIN u 

В результате я бы написал следующий запрос как:

$q='SELECT po.*,ni,lo FROM po LEFT JOIN u ON i=ui ORDER BY wi'

---

Теги:

joke