¿Por qué los espacios adicionales y los saltos de línea en las consultas son malos?

Question

Veo, de vez en cuando, que la gente dice que la consulta SQL que se envía a un servidor desde la aplicación cliente no debe contener ningún salto de línea o espacios adicionales. Una de las razones por las que he escuchado es "¿por qué perder el tráfico de la red?".

¿Hay alguna razón real para hacer que el código sea más difícil de leer y editar a favor de eliminar todos los espacios?

con espacios:

$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); 

Sin espacios:

$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

Es cierto, costará tráfico de red y tiempo de servidor; pero será insignificante en todos excepto en los casos más extremos. Ahora, si está editando el código de FaceBook (o Google, o similar), y optimiza de esta manera las 10 consultas más comunes, entonces hay un punto, ya que se ejecutarán miles de millones de veces al día. Pero en todos los demás casos, creo que es una pérdida de tiempo considerar la eliminación de espacios.

Answer 2

Esto es subjetivo, pero es mejor que la legibilidad espacios adicionales y saltos de línea en cualquier momento cuantos en mi opinión. Y si los estándares de codificación dictan que se rompa la cuerda cada vez, probablemente me vuelva loco.

Answer 3

Si absolutamente debe optimizar espacios y cosas así, no lo haga en su código fuente. En cambio, póngalo a través de una herramienta intermedia automática.

Si estuviéramos hablando de la web, diría que el costo adicional en hacer podría valer la pena para el contenido estático (archivos de script que rara vez cambian y tal) pero sería escéptico sobre hacerlo para contenido dinámico.

En todos los casos:

• Si cambia la fuente, será una pesadilla de mantenimiento.
• Si lo pones a través de una herramienta de compresión/descompresión, ahorrarás mucho más (en promedio) que simplemente eliminar espacios pero a un costo de latencia y tiempo de CPU.
• A menos que tenga una estructura realmente patológica, básicamente constituye una pequeña fracción en comparación con el costo total, incluso si solo consideramos el tamaño de los paquetes TCP y los datos de consulta devueltos.

Quizás no sea relevante en su caso, pero lo mencionaré de todos modos: un enfoque completamente diferente podría ser utilizar un formato de mensaje bien empaquetado con una ID de consulta, en lugar de transferir la consulta cada vez.

Answer 4

Absolutamente. Lo hago todo el tiempo. Yo también:

• eliminar las comillas inversas. ¿Quién los necesita?

Por lo tanto,

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

• uso tan pequeño como posibles nombres para bases de datos, tablas, campos, índices, etc.

Por lo tanto,

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

• Completamente gota Palabras clave innecesarias como AS. Todos los nombres de las tablas son cortos de todos modos (! Regla 2)

Por lo tanto,

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

Como resultado, habría escrito la consulta anterior como:

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

---

Etiquetas :

joke

Answer 5

Aunque es cierto que la eliminación de espacios innecesarios y saltos de línea reduciría la cantidad de datos que envía al servidor de la base de datos, pero no debería preocuparse por eso.

Más bien debería preocuparse por la legibilidad y la mantenibilidad del código. Estas son las dos cosas muy importantes que debe tener en cuenta al escribir el código de software.

Si reducir el tráfico de red fue lo único bueno, entonces podríamos argumentar que debe hacer un Stored Procedure por cada consulta que escriba.

Por ej. Se podría cambiar la siguiente consulta

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`; 

a

CALL GetLoginData(); 

Ahora que sea ~ reducción del 80-95%. Pero ¿vale la pena?

Definitivamente Nº

Hacer las cosas como éstas prefieren hacer la vida de los desarrolladores desgraciado sin añadir ningún valor significativo!

Dicho esto, use la versión reducida del código solo en lugares donde nadie estaría cambiando el código. Por ej. ¡Bibliotecas CSS y JS que nunca cambiarás!

Espero que entiendas el punto, y continuarás escribiendo el código Legible y Mantenible!