Teofileando suavemente con PLSQL

visitas.

Una vez más aquí me encuentro en mi insomnio compartiendo algo de conocimiento. Esta vez quiero mostrarles algo que la mayoría de los desarrolladores de aplicaciones en general (tanto WEB como de cualquier índole) no hacen pues utilizan una práctica donde pretenden resolver sus necesidades a nivel de aplicaciones, generando trabajos innecesarios para la máquina y los servidores de aplicaciones en general. Este tipo de desarrolladores por lo general aman el arte del fashionismo del Front-End y desconocen el poder del Back-End en cuanto a Bases de datos se refiere, pues al sentirse comodos con lenguajes de programación propios para hacer aplicaciones ven a los Sistemas Manejadores de Bases de Datos (Relacionales o orientados o Objetos) como simples bolsas de esas de gran tamaño para guardar los datos, desconociendo que estos a su vez también están diseñados para encapsular lógica del negocio en su contenido.

Esta vez hago uso para mi blog de un Sistema manejador de base de datos de mis preferidos, POSTGRESQL. Para ilustrar algunos conceptos relacionados con el uso de PLSQLs para incluir procesos de la lógica de negocio en el interior de la base de dato misma.

Con el motor previamente instalado y habiendo ingresado como el super usuario procedemos a crear un usuario de nombre frias_user que sera el propietario de nuestro base de datos de demo frias_db y que dispondra de privilegios para crear objetos dentro de la misma. Esto debería ser algo que hasta cualquier Paez debería poder hacer.

Conectados como el usuario recien creado en la base de datos recien creada, generemos algunas tablas, como se ilustra en el siguiente script:


CREATE TABLE frias
(
  idfria serial NOT NULL,
  nombre text,
  cantidad integer,
  CONSTRAINT frias_pkey PRIMARY KEY (idfria)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE frias OWNER TO frias_user;





CREATE TABLE frieros
(
  idfriero serial NOT NULL,
  cedula bigint,
  nombre text,
  CONSTRAINT frieros_pkey PRIMARY KEY (idfriero),
  CONSTRAINT frieros_cedula_key UNIQUE (cedula)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE frieros OWNER TO frias_user;


CREATE TABLE friadas
(
  idfriada serial NOT NULL,
  idfria integer,
  idfriador integer,
  cantidad integer,
  fecha timestamp without time zone,
  CONSTRAINT friadas_pkey PRIMARY KEY (idfriada),
  CONSTRAINT friadas_idfria_fkey FOREIGN KEY (idfria)
      REFERENCES frias (idfria) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT friadas_idfriador_fkey FOREIGN KEY (idfriador)
      REFERENCES frieros (idfriero) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE friadas OWNER TO frias_user;


A modo de tip, aunque las tablas se encuentran en el esquema publico, es siempre un teofilismo crear  esquemas que categoricen la lógica del negocio bajo algún criterio conveniente para la necesidad.

Poblemos las tablas de frias y frieros con algunos registros.

INSERT INTO frias(nombre, cantidad) VALUES ('Aguila Light', 50);
INSERT INTO frias(nombre, cantidad) VALUES ('Corona', 100);

INSERT INTO frieros(cedula, nombre) VALUES (1045670923::bigint, 'Teofilo Gutierrez');

Ahora supongamos que se tiene la necesidad de registrar friadas, un desarrollador paezista desarrollaria primero una serie de consultas como ver si primero hay frias suficientes para pedir, luego actualizaria la tabla de existencias y finalmente insertaría en la tabla de friadas. Generando que el servidor de aplicaciones dialogue tres veces con el motor de base de datos cuando solo podría hacerlo una vez si la lógica del negocio estuviese del lado del SMBD.

El PLSQL que ilustro es educativo, pues no tiene presente muchas consideraciones de transaccionabilidad, el objetivo esta mas enfocado a mostrar el concepto de ver como la lógica de negocio puede llevarse a la Base de Datos y las ventajas que esto conlleva.

Generemos un tipo de dato especial para nuestro procedimiento que nos de un resultado detallado de lo que ocurrio en el proceso. Para ello:

create type registro_friada_tipo as (estado text, descripcion text)

Y finalmente el PLSQL del teofilismo:



Para testear el procedimiento, ejecutamos:

select * from registrar_friada(1045670923::bigint, 2, 10)

Comentarios

Entradas más populares de este blog

Un par de cuadrados para todos

Dominós para todos. Parte I.

Crocancia de cuadrados en abundancia