¿Es una buena idea usar la biblioteca CodeIgniters Active Record para manipular bases de datos MySQL o debería usar SQL?

Question

Estoy empezando a familiarizarme con CodeIgniter y encontré que es compatible con el patrón Active Record.

Me gusta el hecho de que genera el código SQL para usted, así que esencialmente puede recuperar, actualizar e insertar datos en una base de datos sin vincular su aplicación a un motor de base de datos específico.

Hace que las consultas simples sean muy simples, pero mi preocupación es que hace que las consultas complejas sean más complejas si no imposibles (por ejemplo, si es necesario para funciones específicas del motor).

Mis preguntas

¿Cuál es su opinión de este patrón en especial respecto a la implementación CodeIgniters?

¿Hay problemas de velocidad con el ajuste de la base de datos en otra capa?

¿Se vuelve (lógico) complicado al intentar crear consultas muy complejas?

¿Las ventajas salen de las desventajas?

Answer 1

Ok, Primero de todo, el 99% de sus consultas serán simple seleccionar/insertar/actualizar/eliminar. Para este registro activo es genial. Proporciona una sintaxis simple que se puede cambiar fácilmente. Para consultas más complejas, solo debe usar el método de consulta. Eso es para lo que es.

En segundo lugar, proporciona la seguridad de escape & para esas consultas. Acéptalo, tu aplicación probablemente tendrá cientos si no miles de lugares donde se realicen consultas. Estás obligado a arruinar y olvidarte de escapar adecuadamente de algunos de ellos. Registro activo no se olvida.

En tercer lugar, el rendimiento en mi experiencia no se ve dramáticamente afectado. Por supuesto que lo es, pero es probable que alrededor de 0.00001 por consulta. Creo que es perfectamente aceptable para las comprobaciones de seguridad y cordura adicionales que hace por usted.

Por último, creo que está claro que creo que las ventajas son mucho mayores que las desventajas. Tener consultas seguras que incluso el desarrollador más joven pueda entender y no arruinar es una gran cosa.

Answer 2

¿Cuál es su opinión (sic) de este patrón en especial respecto a la implementación CodeIgniters?

No se puede decir mucho sobre la implementación de CI. En general, evito AR para cualquier cosa que no sean las aplicaciones más simples. Si la tabla no coincide con 1: 1 para mis objetos comerciales, no uso AR, ya que dificultará el modelado de la aplicación. Tampoco me gusta la idea de acoplar la capa de persistencia a mis objetos comerciales. Es una violación de la separación de preocupaciones. ¿Por qué un Producto debería saber cómo salvarse? Futher lectura: http://kore-nordmann.de/blog/why_active_record_sucks.html

EDITARdespués del comentario de @kemp, me miró a la Guía del usuario CI para ver cómo se implementan AR:

Como se puede ver en PoEAA un AR es un objeto que envuelve una fila en una tabla o vista de base de datos, encapsula el acceso a la base de datos y agrega lógica de dominio en esa información. Sin embargo, esto no es lo que CI hace. Solo proporciona una API para generar consultas. Comprendí que hay una clase de modelo que amplía AR y que se puede usar para construir objetos de negocios, pero entonces sería más como Row Data Gateway. Consulte PHPActiveRecord para una implementación alternativa.

¿Hay problemas de velocidad con el ajuste de la base de datos en otra capa?

Cada vez que abstrae o fondo algo en otra cosa, puede estar seguro de que esto tiene un impacto en el rendimiento sobre hacerlo en bruto. La pregunta es, ¿es aceptable para su aplicación? La única forma de averiguarlo es haciendo una evaluación comparativa. Lectura adicional: https://stackoverflow.com/search?q=orm+slow

EDIT En el caso de API de creación de consultas simple de CI, supongo que el impacto en el rendimiento será negligible.El ensamblaje de las consultas tomará lógicamente más tiempo que el simple hecho de pasar una cadena de SQL sin formato al adaptador de base de datos, pero eso debe ser solo de microsegundos. Y hasta donde lo he visto en la Guía del usuario, también puede almacenar en caché las cadenas de consulta. Pero en caso de duda, punto de referencia.

¿Se vuelve (lógico) complicado al intentar crear consultas muy complejas?

Depende de sus consultas. He visto consultas SQL bastante desordenadas. Esos no se vuelven más bonitos cuando se expresan a través de una interfaz OO. Dependiendo de la API, es posible que encuentre consultas que no podrá expresar a través de ella. Pero, de nuevo, eso depende de tus consultas.

¿Las ventajas ofrecen las desventajas?

Eso solo usted puede decidir. Si hace que tu vida como programador sea fácil, seguro por qué no. Si se ajusta a sus necesidades de programación, sí. Ruby on Rails se basa en gran medida en ese concepto (AR), por lo que no puede ser tan malo (aunque también podríamos discutir sobre esto :))