Posts Tagged ‘ base de datos

Data Hydrators con Symfony 1.4 y Doctrine

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Muchas veces busqué alguna buena documentación sobre los Data Hydrators de Doctrine más como ejemplos que simples explicaciones y luego de mucha pelea logré entenderlos bien como para trabajar a gusto con ellos por lo que me gustaría dejarlo por escrito por si pueda serles de utilidad.

Me gustaría empezar con el concepto de que son los Data Hydrators haciendo referencia a la documentación oficial de Doctrine en su sitio web.

Doctrine has a concept of data hydrators for transforming your Doctrine_Query instances to a set of PHP data for the user to take advantage of. The most obvious way to hydrate the data is to put it into your object graph and return models/class instances. Sometimes though you want to hydrate the data to an array, use no hydration or return a single scalar value.

Yo lo explicaría diciendo que Doctrine utiliza Data Hydrators para la transformación de los Doctrine_Query que usamos al momento de hacer nuestros DQLs. Es decir, un DQL generado por nosotros nos sirve para generar dinámicamente el SQL necesario para ejecutarlo contra la base de datos y nos devuelve de alguna manera información de la base de datos que por lo general lo hubiésemos denominado un ResultSet. Estos datos devueltos vienen en un formato que Doctrine maneja y los Data Hydrators nos permiten decirle que nos devuelva de cierta manera que podamos manipularlos más fácilmente. A este proceso de transformación se le denomina “hidratar los datos” y nos sirve para manipularlos como objetos, arrays o como un valor único a lo que se le denomina valor escalar. Leer mas

Parametrizando nuestro sistema con symfony 2/2

VN:F [1.9.22_1171]
Rating: 4.0/5 (4 votes cast)

Continúo con lo prometido de seguir con el artículo Parametrizando nuestro sistema con symfony con este segundo artículo sobre esta serie. Aquí veremos como implementar con Symfony unos métodos que nos hagan un poco más sencillo el desarrollo de una aplicación parametrizada.

Habíamos visto en el artículo anterior que podríamos trabajar creando una tabla en la que centralicemos los parámetros de nuestra aplicación según dos puntos importantes.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si estas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

De esta manera lograríamos no tener tantas tablas que simplemente las usamos como parámetro y hacer nuestra aplicación mucho mas fácil de mantener.

En éste artículo veremos como manipular los datos de la tabla parámetro de una forma en la que no necesitemos mucha conversación con la base de datos.

Leer mas

Parametrizando nuestro sistema con symfony 1/2

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Mucho se habla hoy en día de que un sistema parametrizado es mucho mejor que los famosos “códigos en duro” que los programadores solemos escribir dentro del fuente de los programas. Es muy normal ver gente que usa combos de selección múltiple que en realidad van cargados dentro del mismo HTML de la página. El problema ocurre realmente cuando hacemos esto con varias páginas y luego resulta muy engorroso el mantenimiento del sitio ya que hay que buscar todos los lugares en donde lo hicimos a la hora de agregar, quitar o modificar alguna de las opciones de nuestro combo.

Mucha gente acostumbra crear tablas paramétricas para por ejemplo “estados”, “paises”, “tipos”, etc. Considero, y es una opinión muy personal, que cuando estas tablas son creadas habría que analizar 2 puntos a fin de determinar si las mismas podrían ir dentro de la estructura que voy a proponer con este artículo.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si éstas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

Cabe mencionar que creando tablas como las descriptas arriba vemos un crecimiento muy grande en el número de tablas de la base de datos y por supuesto un Diagrama Entidad Relación (DER – ER) muy complejo para graficar ya que la mayoría de las tablas suelen ser de este tipo.

Tomando en cuenta esto, propongo que trabajemos con una tabla a la cual denominaremos “parametro” y con la ayuda de Symfony y los artículos de la serie Personalizando el objeto sfUser de Symfony veremos como centralizar los datos paramétricos dentro de un solo lugar y los almacenaremos dentro de la sesión del usuario activo del sistema.

Leer mas