Para conocer los antecedentes de esto, consulte http://drupal.org/node/1067802 .
Dado todo eso, ¿qué situaciones existen en las que podría querer usar db_select (), o debería confiar únicamente en db_query?
fuente
Para conocer los antecedentes de esto, consulte http://drupal.org/node/1067802 .
Dado todo eso, ¿qué situaciones existen en las que podría querer usar db_select (), o debería confiar únicamente en db_query?
Hay 5 razones para usar SelectQuery
Está creando consultas dinámicas con un número variable de condiciones, uniones, campos, etc. Vea field_read_fields () para ver un ejemplo.
Desea utilizar los llamados Extensores . Los extensores de ejemplo son PagerDefault (reemplaza pager_query () ) y TableSort (reemplaza tablesort_sql () ). Estos permiten agregar funcionalidades adicionales a SelectQuery. Consulte también ¿Cómo hacer tablas ordenables con un buscapersonas con datos de una tabla personalizada? . Un ejemplo: node_page_default () .
Desea permitir que otros módulos alteren sus consultas. Luego puede agregar las llamadas etiquetas y SelectQuery llamará automáticamente al enlace alternativo correspondiente para esa etiqueta. Confío mucho en esto con mi módulo Privatemsg (ya lo hicimos en D6 con un generador de consultas personalizado).
Si desea / necesita usar el sistema node_access para mostrar solo los nodos que el usuario puede ver. Simplemente agregue la etiqueta 'node_access' a su consulta $. Esto reemplaza db_rewrite_sql ().
SelectQuery tiene algunas características que ayudan a que su código funcione igual en todas las bases de datos compatibles. Por ejemplo, hay SelectQuery :: orderRandom () . Y si tiene una condición LIKE, -> condition ('field', $ value, 'LIKE') se asegurará de que siempre sea una comparación entre mayúsculas y minúsculas. En D6, tenía que usar LOWER () para lo que era mucho más lento. Pero AFAIK, no hay más que estos dos en este momento.
Si ninguna de estas razones se aplica a un caso específico, use db_query ().
La documentación sobre
db_query()
dice:fuente
Siempre uso db_select ya que prefiero la legibilidad, la mantenibilidad y la compatibilidad cruzada de bases de datos en lugar de pequeñas ganancias de rendimiento. Además, creo que los números dados en el número mencionado dan una imagen incorrecta del rendimiento general. Estamos hablando de una diferencia de 300 microsegundos en una consulta que, al devolver más de una columna, a menudo se ejecuta en el rango de varios milisegundos. Y no me sorprendería si hay algunos gastos generales por única vez (carga de clase) y, por lo tanto, que las diferencias para una solicitud completa (página) son mucho menores.
fuente