"Gaceta de Linux...haciendo Linux un poco más divertido!"


Configuración estándar de Base de Datos con Perl y PostgreSQL: Parte 3

Por Mark Nielsen

Traducción al español por Ricardo A.Frydman
el día 24 de Julio 2002, para La Gaceta de Linux


  1. Introducción (camino largo)
  2. Configuración de Base de Datos Estándar (SDS)
  3. Script Perl para configurar mi entorno SDS con Perl y PostgreSQL
  4. Cómo el script Perl se configura
  5. Conclusiones
  6. Referencias

Introducción

Este artículo trata de lo siguiente:
  1. Dado un diseño de Base de Datos, crear las tablas, secuencias, procedimientos, vistas, tablas de respaldo, timestamps, e identificadores unique.
  2. Para el lenguaje Perl, crear todos los módulos and scripts de ejemplo para un servidor web.
  3. La Base de Datos y páginas asumirán que hay autenticación de usuarios. La tabla de usuarios, que tendrá los nombres y claves de las cuentas, se llamará "usuarios".
  4. Crear todas la "cuestiones" involucradas entre el diseño de la Base de Datos y las páginas web. Así, te televa de crear la información de Base de Datos, módulos Perl, incluso provee ejemplos de código script de ejemplo para acceder a la BD utilizando módulos Perl. Todo lo que hay que hacer es modificar los scripts en Perl y personalizarlos.
  5. Quitar el peligro de administradores de BD y administradores web no-programadores complicándole la vida a los programadores. También, hacer posible para un programador novicio, configurar toda la BD, módulos Perl, y scripts de ejemplos de manera de poder comenzar a experimentar y aprender (ésto va a ser de mucho valor en mis clases avanzadas de web/BD en eastmont.net).
  6. Ejecutar una Configuración de BD Estándar (SDS), la cual será utilizada para proyectos futuros sin inmportar el servidor de BD y lenguaje de programación que se utilice.

Trabajé para muchas compañías y proyectos diferentes. Cada uno de ellos con su estilo de programación y manera de hacer las cosas. Usualmente no muy bien pensadas, debido a la presión de los tiempos y posponiendo las consecuencias. La Parte 3 de Pêrl y PostgreSQL está dedicada a mí, de manera de poder estandarizar la manera de hacer las cosas, permaneciendo profesional (estructura de BD y módulos perl profesionales y semi-profesionales scripts de ejemplo perl).

Cuando se estandariza con un buen código, todo se vuelve más fácil. Personalmente, nunca voy a participar en otro proyecto que no use un sistema de BD con procedimientos estándar con id unique 100% en cada tabla. Simplemente, no tomaré el trabajo (tengo suficientes ofertas de trabajo). No quiero pertenecer a un ámbito no-profesional nunca más (a menos que acepten hacerlo de manera profesional). Pierdo mi tiempo y el de ellos. Punto Final. Estoy más interesado en los aspectos de negocio de una compañía que requiera habilidades de programación que en programar en sí mismo. Me gusta configurar las cosas e investigar y desarrollar para mejorar, pero que otros hagan después el trabajo sucio.

Una gran compañía para la que trabajé, tenía un gran diseño de BD, pero los programadores perl estaban a merced de los administradores de la BD. Un inmanejable servidor de BD popular es una pesadilla. Aunque respeto a los administradores de BD, siento que un verdadero programador debería estar a cargo de la BD, y el administrador debería ser una guía y no un dios. Los programadores no deben saber cómo manejar la BD apropiadamente, allí es donde debería entrar el administrador, para aprobar cosas, no para prevenir que sean hechas. Encuentro extremadamente frustrante pelerame con administradores de BD cuando se suponen que están para ayudarnos. Los admninistradores de red ayudan a los adm. de BD, éstos a los programadores, quienes a su vez reportan a sus jefes, quienes interactúan con las secretarias, contadores, clientes, vendedores, y otros dentro y fuera de la empresa. En otras palabras, la única justificación para los de abajo, es si están sirviendo a los de arriba para ayudar a hacer su trabajo. El Señor sabe que he visto muchos excéntricos de la computación, que no tenían idea sobre los negocios. La gente de informática sólo son valiosos si acompañan a los objetivos de otros en las compañías.

Habiendo hecho mi discurso acerca de mis peleas diarias con los admin.de BD, esta parte 3, pretende también eliminar o al menos reducir drásticamente la necesidad de uno de ellos. Mi script Perl borra las tablas, si tienes datos en un servidor activo, puede ser algo malo para lo que necesitarás un adm.de BD. Sin embargo, H¡hago copias de todas las tablas que borroy quiero agregarle la capacidad de repoblar de datos de una tabla a otra cuando las columnas son cambiadas o añadidas. Con esto, un adm. de BD, pierde el poder de estrangular al programador para tener su trabajo hecho, o mejor, si podemos proveer un sistema profesional que un sobrepagado adm. de BD apruebe, de manera que se vuelvan más baratos. Dicho esto, los programadores sobrepagados, pueden causar tantos problemas como los adm. de BD! Sólo me muevo en un mundo donde instalo mi SO desde cero, instalo Perl, Apache, Zope, Python, PostgreSQL, MySQL de cero, y el resultado final es una bella y/o funcional página web que la gente puede usar. Cualquier otra cosa que me cause problemas para alcanzar este objetivo, sea un admin de BD, de red, etc es un obstáculo que debe ser evacuado. Así es como pienso. Tengo un gran respecto por toda clase de administradores, pero ellos sirven a los programadores, y puedo ver incontables veces cómo los programadores se ven restringidos y asfixiados cuando saben que una compañía o departamento está en problemas. Cuando los adm.de redes o BD hacen felices a los programadores, todo el mundo lo está (también saben cómo prevenir que los programadores se pongan como poseídos cuando es necesario!)

Con exactos procedimientos, vistas, secuencias, id únicos. timestamps, estados activo/inactivo para todas las tablas, estándar, los admin. de BD deberían estar felices de permitir a los programadores diseñar tablas de BD así como aprobar el resultado final de la BD. Después de todo, si mi script perl configura toda la BD, y los módulos Perl para acceder a los procedimientos almacenados en ella, no hay nada que el adm. de BD pueda hacer más que aprobar el diseño y hacerle cambios (porque probablemente el programador no sabe cómo diseñarla correctamente). También, los admin.web pueden ser sofocantes si no son programadores. Si el admin. web limita a los programadores a usar módulos Perl en el acceso a la BD, entonces, uno que no es programador se puede sentir cómodo de no estrangular al programador. Si todo está estandarizado, entonces el novicio e inmaduro programador aspirante a punto-com que no sabe programar bien, y no sabe nada de instalar SO o configurar BD o servidores web, puede al menos tener algo de trabajo con lo estándar de manera que no anden creando montones de código, solo por el hecho de hacerlo de manera "piola".

Finalmente, todos los involucrados pueden causar problemas intentando ejecutar scripts Perl. Esto esperemos que sea el punto inicial para modificar las cosas. Existen un montón de cosas que me gustaría agregar. Estoy contento con esto llamado "Versión 1". Estoy intentando con PHP, Python, y posiblemente módulos Java y páginas web para la "Versión 2", modificando las tablas (más que borrándolas y recreándolas) para sistemas en vivo en la Versión 3, y un GUI para la Versión 4 (aunque éste se puede hacer al mismo tiempo).

Obviamente, llegar a la V4 llevará mucho tiempo. Me llevó 4 meses llegar hasta aquí. La nayoría del trabajo es un debate conmigo mismo acerca de qué debo hacer, más que llevarlo a cabo. Cuando desarrollas, se desecha un montón de código porque se te ocurren mejores formas de hacerlo, entonces te dedicás a hacer más. Por ahora, estoy deshaciéndome de código que no me gusta y lo rehago, lo que me lleva más tiempo, pero da mayores recompensas, lo cual es una mentalidad refrescante y completamente diferente, comparado con el boom puntocom, donde tienes un jefe no-programador sobre tí exigiéndote teminar sin importar cuan horrible quede el código.

Configuración Estándar de Bases de Datos (Standard Database Setup - SDS)

SDS es una creación mía acerca de manejo de systemas de BD. Ya sé que hay un montón de aclaraciones y cosas que agregar, pero llamaré a ésta la versión 1. En algún momento, tendré un enlace a www.tcu-inc.com con actualizaciones a mi sistema de BD. Además, llamaré a mi Script Perl y material relacionado MAPPS, y estarán localizadas en www.tcu-inc.com para Octubre. Planeo dejar ejecutar MAPPS para crear sus aplicaciones web en línea en mi sitio. No es que quiera que usen la aplicación en el sitio, sino que la creen y prueben allí, y después la descarguen. Si tan sólo una persona quisiera unítseme en crear un sistema de BD de clases utilizable en todas las necesidades de la BD, entonces lo pondré en sourceforge, o donde sea, de manera que puedan colaborar. Este sistema es realmente inmaduro, y no he intentado leer ninguna documentación acerca de algo similar. Mi sistema SDS está basado en todos los errores y dolores de cabeza de los que fui testigo en todos estos años, propios y ajenos. Estoy desarrollando SDS para usarse en cualquier aplicación y crear una interfase sólida de manera que no interese el proyecto, si sabes SDS, puedes fácilmente comprender y agregar cualquier proyecto. Esto reduce drásticamente la necesidad de pagar más a un programador, ya que no necesitas contratar a algún dios para que genere un montón de código inentendible (espero...).

Las dos opciones, usar una tabla llamada TABLENAM_diff y seleccionar los procedimientos guardados no están hechos en mis sripts. La razón es que sólo descargué la versión beta de PostgreSQL 7.2 y no me enredé con los procedimientos guardados que devuelven múltiples variables (o cursores). Todavía utilizo procedimientos guardados que devuelven sólo una sola variable. Cuando PostgreSQL 7.2 salga, podré hacer realidad procedimientos guardados que devuelvan montones de información.

SDS versión 1.0 es:

Standard Database Setup (SDS) versión 1.0. 
Copyright por Mark Nielsen, 9/2001. 

1. Todas las tablas deben contener:
   a. Una clave primaria igual a TABLENAME_id.
   b. Timestamps para la fecha de creación y modificación, date_created
      y date_updated. 
   c. Habrá una tabla de respaldo llamada TABLENAME_backup. 
   d. Todos los campos están en minúsculas.
   e. Un campo activo cuyo estado 0 is inactivo y 1, activo. 
   f. Todas las claves externas deben tener la extensión _fk, salvo los campos que terminen en "_id"
   g. Todos los nombres de campo con "_id" en la definición de la tabla serán tomados automáticamente como clave con referencia externa. Un campo con el nombre "TABLENAME_id" tendrá una referencia externa a la tabla "TABLENAME" con su clave primaria "TABLENAME_id".
   h. Se crearán vistas para activos, inactivos (borrados), y evacuados. 
   i. Las funciones Insert, Update, Delete, Copy, Change, Purge, Unpurge, PurgeOne, y UnpurgeOne también serán usadas para todas las modificaciones de la BD donde las funciones serán llamadas "TABLENAME_FUNCTION_sql".     
   j. Cuando los procedimientos guardados puedan devolver múltiples variables, todas las sentencias select serán ejecutadas a través de procedimientos guardados también. Todos los procedimientos guardados select terminarán en "_select_sql".
Los dos tipos de procedimientos guardados select serán:
      1. Dado un número de identificación único, la sentencia select requerirá todos los campos de esa columna. Este tipo será llamado "TABLENAME_select_sql". 
      2. Todas las otras sentencias select serán hechas a medida. Las sentencias select se pueden volver muy complicadas. Es preciso que todas las sentencias select personalizadas sean creadas con procedimientos propios.
   k. Toda modificación a cualquier tabla será regoistrada en "TABLENAME_backup".
      Las modificaciones se harán a través de procedimientos guardados y se llevarán registros de éstas.
"backup_id" será la clave primaria de todas las tablas de respaldo.
   l. Todos los selects de tablas serán guardados como una opción usando la tabla
      "TABLENAME_select" si se desea cuando se cree la tabla.
      "TABLENAME_select" contendrá los campos select_id, date_created, 
      date_updated, TABLENAME_id, error_code, y misc.   
   m. Un método opcional para grabar los agregados y cambios de la BD respecto a las diferencias, puede ser usdao, pero debe seguir los siguientes parámetros. Esto no se incluirá en las opciones por defecto del MAPPS.
      1. La tabla de resplado deberá llamarse TABLENAME_diff.  
      2. "diff_id" será la clave primaria para cada tabla. 
      3. Cada tabla diff contendrá exactamente estos campos.
         a. diff_id 
         b. date_updated : Registro de la fecha de ingreso de los datos. 
         c. diff_data : Es la diferencia de datos entre ésta entrada y 
	 la anterior.
         d. diff_method : Describe la diferencia con el método utilizado. 
	 Es arbitrario y depende del programador. 
	 Una lista de métodos pre-definidos:
            1. "diff" o "gnudiff" corresponde al GNU diff. 
	    La versión se debe proveer o registrar en algún lado.
            2. "subversión" en relación a la sub-version. 
            3. cvs no será una opción estándar. "subversion" reemplaza
               cvs, por lo tanto, por ahora SDS es realmente sólido, 
	       una subversion de subversion.org estará pronto lista. 
         e. diff_prev : Es la diff_id previa con la que se está comparando. 
	 Esto se realiza para el caso de ser borrada diff_id, poder verificar 
	 si existe un error. 
         f. fieldname : Es el campo de la columna a la cual pertenece el dato.
         g. primary : Es la clave primaria de la columna en la que estamos 
	 buscando
         h. error_code : "start" significa que no hay una diff_id previa con 
	 la cual comparar.  "diff" significa que sí la hay. "stop" significa
	 que la clave primaria ha sidi borrada.
         Son posibles otros errores. 
   n. Una entrada 0 en una clave extraña significa nulo. Todas las columnas con
   una clave primaria 0 deberían tener espacios en blanco para textos y 0 como
   valores numéricos o el valor por defecto (si existiera).

2. Los nombres únicos que no pueden utilizarse son:
   a. "error_code", "backup_id", "date_created", "date_updated",
      , "diff_id" y "active" son campos reservados. 

3. Prácticas estándar con Módulos Perl Modules y otros lenguajes de programación. 
   a. Todos los Módulos Perl (o en otros lenguajes) crearán objetos cuyos 
      métodos corresponderán a cada procedimiento guardado.
      La convención de nombrar para cada método deberá ser exactamente el 
      nombre de la función sql menos el nombre de la tabla y "_sql".
      Así, "TABLENAME_FUNCTION_sql" se convierte en "FUNCTION" en el Módulo 
      Perl. Habrá una correspondencia exacta de uno a uno entre las funciones 
      sql y los métodos perl, salvo las funciones sql o métodos perl 
      personalizados.
   b. Todos los métodos perl personalizados usan procedimientos guardados para
      los cambios y selecciones de datos (cuando pueden devolver múltiples
      variables).

     
4. Prácticas Estándar de procedimientos guardados comunes.
   a. Todos los procedimientos guardados comunes sólo pueden modificar datos
      utilizando alguno de los procedimientos predefinidos. No sirven para
      cambiar/insertar datos (N.del T.: sic).
   b. Todas las sentencias de selección deben utilizar procedimientos guardados
      (cuando éstos puedan devolver múltiples valores).

5. Prácticas Estándar par scrit perl/páginas web.
   a. Todos los scripts perl y otros lenguajes utilizarán siempre módulos perl
      para interactuar con las BD. Todas las modificaciones, inserciones o
      vistas de datos serán realizadas a través de un módulo.

Script Perl para configurar mi entorno SDS con Perl y PostgreSQL

Aquí hay un enlace para los script perl y archivos genéricos que utilizo, Files.tgz. También puedes acceder a los archivos descomprimidos yendo a mi directorio Test. Baja éste en un directorio vacío en tu sistema Linux. Corre una BD PostgreSQL 7.1 a la cual tengas acceso. Luego sigue las instrucciones.
  1. Instala PostgresSQL 7.1, el servidor web Apache, configúralo para utilizar conexiones a BD persistentes, hazlo ejecutar los archivos *.pl como scripts de perl, instala los módulos Perl DBI, DBD::Pg, y BlowFish. Si tienes algún problema, por favor revisa las referencias que aparecen en éste artículo.
  2. "cd" al directorio adonde descargaste estos dos archivos y ejecuta:
    tar -zxvf Files.tgz
    mv misc/nielsen/Test /tmp/
    cd /tmp/Test/
    mv Create_Functions.pl.txt Create_Functions.pl
    chmod 755 Create_Functions.pl
    
  3. En teoría, ya estamos listos. He provisto una BD de ejemplo llamada "sample". Debes modificar dos archivos Config.txt. uno situado en el directorio principal, el otro en el directorio" sample". He configurado ciertas variables web apuntando a /usr/local/apache que es la instalación estándar del apache cuando lo descargas y lo instalas desde cero. Si estás utilizando el apache que viene con tu distribución, por favor modificá las variables de esos dos archivos. En teoría, todo lo que hay que hacer para configurar tu BD y utilizar las páginas web es ejecutar un comando:
    /tmp/Test/Create_Functions.pl sample
    
    e ir a la página http://127.0.0.1/sample/sample/index.html en tu máquina.

En el caso que no puedas ejecutar los scripts, aquí está la salida de los comandos SQL, módulos Perl y scripts web.

  1. comandos
  2. Módulos Perl
  3. páginas web HTML

Cómo configurar el script perl para trabajar

Docs/SDS.txtExplica cómo el SDS está diseñado.
Config.txttiene dos variables utilizadas para el script perl.
Templates/Constants.pm
Templates/Set_Info.pm_header
Templates/Set_Info.pm_template
Templates/Email.pm_header
Templates/Get_Info.pm_header
Templates/Misc.pm
Los módulos utilizados para todas las Bases de Datos.
Templates/Custom.sql
Templates/Generic.fun
Son los dos archivos que son modificados para luego ser ejecutados en la BD. Generic.fun se ejecuta para cada tabla.
Templates/Custom_Html1.html
Templates/Custom_Lists.html
Estas dos páginas web/scripts perl se usan para todas las tablas.
Templates/Error_No_User.pl.txt
Templates/Error_No_User.pl
Templates/Password
Templates/htaccess
Estos 4 archivos se usan para autenticar a los usuarios.
Create_Functions.pl.txtEste es el archivo principal ejecutable y debe ser renombrado a "Create_Functions.pl".
sample/Custom/Sql/users.sql
sample/Custom/Sql/contact.sql
sample/Custom/Sql/class.sql
sample/Custom/Sql/students.sql
Estos son los comandos sql comunes a ser ejecutados luego que el script perl crea la configuración por defecto de la BD.
sample/Config.txtEs la configuración para la BD.
sample/Tables.txtEste es el archivo de texto que define todas las tablas para nuestra BD.

Conclusiones

Al final de cuentas, logré un sistema que usa totalmente software libre y hace el 90% del trabajo para mí al darle una lista de tablas de BD. Además, mi sistema entero es sistemático y trata de reutilizar código, de manera que me es muy fácil comprender cómo usar los procedimientos sql, métodos perl, y scripts, ya que todos utilizan el mismo código y son utilizados de la misma manera. Descubrí que siendo estrictos al hacer las cosas sistemáticamente, son más fáciles de realizar, de comprender, de modificar y de anexar. La clave es encontrar que es lo que se utiliza más de una vez y replicar ese proceso.

Estoy muy contento con el resultado. Ahora puedo lanzar páginas web a lo loco. No tendré que preocuparme más por el proceso, ya que todo está probado. Hay montones de cosas que me gustaría hacer, cambiar, agregar, pero traté de hacer primero lo más importante. Además, lleva un tiempo pensar en los problemas, ya que a veces me pregunto "quier realmente hacer ESO?", lo que lleva su tiempo.

Espero que les permita crear páginas web rápido y les quite bastante stress en el desarrollo de sus sistema BD/web. Mis objetivos futuros son crear con mi script Perl código Python y PH, también como hacer una bella interfase GUI (también basada en web o independientes de las Xwindows) para ayudar a crear tu BD, chequear errores, generar reportes, crear gráficos, modificar la Bd, etc. He visto montones de sistemas que lo hacen, pero son dependientes de interfases KDE oGNOME. En mi opinión, una linda solución Python/TK estaría bien, ya que compilas el Python y te corre en cualquier entorno Xwindows. Quiero que sea utilizable por todos, no sólo quienes usan GNOME o KDE. Además, Python puede generar código JAVA, lo cual puede ser muy útil. Además, no veo otros sistemas que traten de forzar una implementación de hacer las cosas de manera estándar. Mi (o nuestra) interfase GUI intentará utilizar el SDS o algún otro modo estándar de hacer las cosas. Una cosa que me gustaría reiterar es:me gustaría en futuras versiones crear módulos y scripts PHP y Python. Porqué lo considero tan importante? Te permite cambiar de lenguaje de programación rápidamente (créanme, es un dolor de cabeza soportar múltiples lenguajes). Si tu programador es un idiota, y el que lo reemplaze usa otro lenguaje, sabés qué! No hay problema! Nuevamente, intentando reducir el costo de tener admin. de BD, de red y programadores. Cualquier cuello de botella debe ser eliminado. Si no intentas nuevos desafíos, mereces perder. Quiero que mi sistema respalde a los buenos muchachos y deje a los malos en el polvo.

Lo que hago acá debería ser muy fácil de usar con Mason, ASP, u otras maneras interesantes de hacer páginas web. En ASP y Mason, no querrás usar el módulo CGI, así que reemplázalo con su proio método de manejo de búsquedas. Algo en lo que insisto, es el uso de creación de objetos y conceptos. Ya que puse todo el mejor código en módulos perl, pueden ser utilizados en Mason, ASP, o el método que elijas para hacer páginas web. Intentando crear código que pueda ser usado bajo cualquier cicunstancia, espero poder usarlo, no importa donde vaya. Estoy pensando en mi carrera e intentando reducir obstáculos. Espero que tenga sentido! Disfrútenlo!

P.D. Estoy harto de clamar a los admin. de BD que ayuden a los programadores. Todavía creo que es así. El admin. de BD no hace un producto final. El producto final es el resultado del programador, que necesita un servidor web (manejado por el admin. web), una BD (manejada por el adm. de BD), y una red (manejada por el admin. de redes). Sucesivamente, el producto final se entrega al jefe de programadores, que a su vez lo entrega a los clientes o gerentes. Finalmente, hay una cadena de soporte, en los cuales el cliente y empleador están por encima y los locos de las computadoras debajo. Cualquiera que necesite su producto terminado es un facilitador y está debajo tuyo, incluso tengan más autoridad y ganen más. Con su permiso, deben establecer líneas razonables y prevenir al programador de hacer cosas estúpidas.

Referencias

  1. Parte 2: PostgreSQL: procedimientos Perl con with PL/pgSQL
  2. Parte 1: PostgreSQL: procedimientos Perl con PL/pgSQL.
  3. Artículos de Branden Williams sobre PostgreSQL.
  4. http://techdocs.postgresql.org/oresources.php
  5. http://techdocs.postgresql.org/
  6. Algunos links que no tienen que ver con éste artículo, pero considero para los futuros.
  7. Si este artículo cambia, estará disponible aquí http://www.gnujobs.com/Articles/24/PP3.html

Mark Nielsen

Mark trabaja como consultor independiente donando tiempo a causas como GNUJobs.com, escribiendo artículos, software libre, y trabajando como voluntario en eastmont.net.


Copyright © 2001, Mark Nielsen.
Licencia de Copia http://www.gacetadelinux.com/copying.html
Publicado en el Número 72 de Gaceta de Linux, Noviembre 2001