You are on page 1of 8

UNIVERSIDAD NACIONAL

ESCUELA DE INFORMÁTICA
CATEDRA DE INGENIERÍA DE SISTEMAS
Tarea: Intercambio Tecnológico

Grupo 32

Integrantes:

Álvaro Granados Narváez 113430425


Luis Pérez Herrera 701830468
Pablo Sandoval Barrantes 401940201
Yeisson Herrera Carmona 206500915

Profesor: Rafael Alvarado A.

Fecha: 26/02/2011

1
Universidad Nacional Ingeniería de Sistemas III Cátedra de
Escuela de Informática I Ciclo 2011 Ingeniería de Sistemas

Tarea: Intercambio Tecnológico

1. Introducción

Durante los cursos de Ingeniería I, II y III, cada grupo ha resuelto diferentes


situaciones de origen técnico, administrativo, de relaciones humanas, y otros. Que de
una u otra forma han resuelto, generalmente realizando un proceso de investigación.

La presente actividad consiste en que los estudiantes expongan a sus compañeros un


hallazgo y la solución implementada con el propósito de reforzar el aprendizaje por
medio de las experiencias vividas en los proyectos. Mediante un diálogo técnico, los
estudiantes podrán describir el proceso de investigación que realizaron, de tal forma
que los compañeros y profesores conozcan y puedan aplicar lo aprendido en futuros
proyectos, o en el proyecto que actualmente desarrollan.

1.1 Objetivos
• Promover el aprendizaje colaborativo entre estudiantes y profesores.
• Exponer los hallazgos, opciones y solución que implementaron durante el
desarrollo de su proyecto en materia de las TIC

1.2 Problema u oportunidad de mejora.

Sabemos que un sistema usualmente tiene mucha participación la base de datos, esto
lleva a un criterio que si la base de datos es solida y está bien diseñada, tendrá un
nivel de éxito mayor, con esto y debido a que el sistema que nuestro grupo esta
implementado tiene un nivel de consultar exigente, múltiples datos y acceso de
múltiples usuarios a una misma consulta, sin olvidar que por la magnitud del sistema
contiene una número de tablas a considerar. Se presento el problema de cómo hacer
frente a esta programación de la base de datos, si implementábamos un
procedimiento para cada instrucción o solicitud eso sería muy enorme y luego difícil de
manejar.
Con lo anterior surgió la siguiente interrogante e investigación; ¿Cómo optimizar los
procedimientos almacenados de tal forma que tan solo con una llamada podamos
implementar varios tipos de consultas o solicitudes a la base de datos?

2
1.3 Metodología de investigación.

• Listar los hallazgos técnicos más relevantes.


• Seleccionar al menos un hallazgo con importancia relevante y solución técnica
importante que se describirá brevemente.
• Se explica brevemente, cómo investigaron o llegaron a una solución; ya sea
buscando a un experto, leyendo manuales, artículos, buscando en Internet,
prueba y error, etc.
• Describir y documentar el hallazgo seleccionado (opciones de solución,
conclusiones y recomendaciones).

1.4 Opciones de solución

Es preciso explicar cómo se implementa los procedimientos almacenados según lo


aprendido dentro de la carrera, porque cada solicitud ya sea eliminar, consultar,
insertar y modificar, se hace un procedimiento almacenado.
Por ejemplo si tuviéramos la tabla Persona:

/*==============================================================*/
/* Table: PERSONA */
/*==============================================================*/
create table PERSONA (
CEDULA int not null,
PRIMER_NOMBRE varchar(50) null,
SEGUNDO_NOMBRE varchar(50) null,
APELLIDO_MAR varchar(50) null,
APELLIDO_PAR varchar(50) null,
TELFONO varchar(12) null,
SEXO char null,
CELULAR varchar(12) null,
DIRECCION varchar(50) null,
FECHA_NACIMIENTO datetime null,
constraint PK_PERSONA primary key (CEDULA)
)
Go

Deberías de tener un procedimiento almacenado para cada tipo de solicitud de la


siguiente manera:

/*******----ADD-----******/

CREATE PROCEDURE SP_ADD_PERSONA


@CEDULA INT,
@PRIMER_NOMBRE VARCHAR(50) , @SEGUNDO_NOMBRE VARCHAR(50),
@APELLIDO_MAR VARCHAR(50) , @APELLIDO_PAR VARCHAR(50),
@TELEFONO VARCHAR(12) , @SEXO CHAR,
@CELULAR VARCHAR(12) , @DIRECCION VARCHAR(50),
@FECHA_NACIMIENTO DATETIME
AS
SET NOCOUNT ON

3
BEGIN TRY
BEGIN TRAN
INSERT INTO PERSONA(CEDULA,PRIMER_NOMBRE, SEGUNDO_NOMBRE,APELLIDO_MAR,
APELLIDO_PAR,TELEFONO , SEXO ,CELULAR, DIRECCION,FECHA_NACIMIENTO)
VALUES(@CEDULA,@PRIMER_NOMBRE, @SEGUNDO_NOMBRE ,@APELLIDO_MAR ,
@APELLIDO_PAR ,@TELEFONO , @SEXO ,@CELULAR , @DIRECCION ,
@FECHA_NACIMIENTO )
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
GO

/*******----DEL-----******/

CREATE PROCEDURE SP_DEL_PERSONA


@CEDULA INT
AS
SET NOCOUNT ON
BEGIN TRY
BEGIN TRAN
DELETE FROM PERSONA WHERE CEDULA = @CEDULA
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
GO

/*******----UPD-----******/

CREATE PROCEDURE SP_UPD_PERSONA


@CEDULA INT, @PRIMER_NOMBRE VARCHAR(50), @SEGUNDO_NOMBRE VARCHAR(50),
@APELLIDO_MAR VARCHAR(50), @APELLIDO_PAR VARCHAR(50),@TELEFONO VARCHAR(12),
@SEXO CHAR(1), @CELULAR VARCHAR(12), @DIRECCION VARCHAR(50), @FECHA DATETIME
AS
SET NOCOUNT ON
BEGIN TRY
BEGIN TRAN
UPDATE PERSONA SET CEDULA = @CEDULA, PRIMER_NOMBRE = @PRIMER_NOMBRE,
SEGUNDO_NOMBRE = @SEGUNDO_NOMBRE, APELLIDO_MAR = @APELLIDO_MAR,
APELLIDO_PAR = @APELLIDO_PAR, TELFONO = @TELEFONO, SEXO = @SEXO,
CELULAR = @CELULAR, DIRECCION = @DIRECCION, FECHA_NACIMIENTO = @FECHA
WHERE CEDULA = @CEDULA
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
GO

/*******----SLT-----******/

CREATE PROCEDURE SP_SLT_PERSONA

4
@COD_PROCEDIMIENTO INT, @DESCRIPCION VARCHAR(50)
AS
SET NOCOUNT ON
BEGIN TRY
BEGIN TRAN
SELECT P.CEDULA,
P.PRIMER_NOMBRE,P.SEGUNDO_NOMBRE,P.APELLIDO_PAR,P.APELLIDO_MAR,
P.TELFONO,P.SEXO,P.CELULAR,P.DIRECCION,P.FECHA_NACIMIENTO FROM PERSONA P
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
GO

CREATE VIEW VW_PERSONA AS


SELECT P.CEDULA, P.PRIMER_NOMBRE,P.SEGUNDO_NOMBRE,P.APELLIDO_PAR,P.APELLIDO_MAR,
P.TELFONO,P.SEXO,P.CELULAR,P.DIRECCION,P.FECHA_NACIMIENTO FROM PERSONA P
WHERE P.CEDULA = P.CEDULA
GO

Ahora supongamos que tenemos 12 tablas en total tendríamos que hacer 48


procedimientos almacenados diferentes. Esto requeriría mucho más tiempo, y también
requeriría que la base de datos tenga más cosas y cuando implementemos esto a
nivel del código tendríamos que estar consultando a 48 procedimientos diferentes.

Sin embargo gracias a la experiencia de compañeros en el desarrollo de otros


sistemas y a la consulta de colegas expertos en el área logramos dar con la siguiente
solución:
Supongamos que tenemos la tabla Artículos:

/*==============================================================*/
/* Table: Articulo */
/*==============================================================*/

CREATE TABLE Articulos(


psCodigo varchar(100) not null,
psDescripcion varchar(100) null,
plBloqueado varchar(1) null,
poCategoria varchar(100) null,
poUnidad varchar(100) null,
poProveedor varchar(100) null,
poBodega varchar(100) null,
psComentario varchar(100) null,
pbExistenciaReal numeric(18,2) null,
pbExistenciaMin numeric(18,2) null,
pbVolumen numeric(18,2) null,
pbCostoUnidad numeric(18,2) null,
psEmpaquetado varchar(100) null
)
GO

Para no tener que implementar los procedimientos insertar, eliminar y modificar por
separado se hace lo siguiente:

/*******----procedimientos de ingresar, modificar y eliminar---********/

5
alter PROCEDURE SP_IMEARTICULO
@MODO int, @PSCODIGO VARCHAR(100),
@PSDESCRIPCION VARCHAR(100),
@PLBLOQUEADO VARCHAR(1),
@POCATEGORIA VARCHAR(100),
@POUNIDAD VARCHAR(100),
@POPROVEEDOR VARCHAR(100),
@POBODEGA VARCHAR(100),
@PSCOMENTARIO VARCHAR(100),
@PBEXISTENCIAREAL NUMERIC(18,2),
@PBEXISTENCIAMIN NUMERIC(18,2),
@PBVOLUMEN NUMERIC(18,2),
@PBCOSTOUNIDAD NUMERIC(18,2),
@PSEMPAQUETADO VARCHAR(100)
AS
BEGIN TRY
BEGIN TRAN
IF @MODO=1
BEGIN ----- ingresa articulos
INSERT INTO Articulos
VALUES(@PSCODIGO,@PSDESCRIPCION,@PLBLOQUEADO,@POCATEGORIA,@POUNIDAD,
@POPROVEEDOR,@POBODEGA,

@PSCOMENTARIO,@PBEXISTENCIAREAL,@PBEXISTENCIAMIN,@PBVOLUMEN,@PBCOSTOUNIDAD,@PSEM
PAQUETADO)
END
IF @MODO=2
BEGIN -------actualiza articulos
UPDATE Articulos SET psDescripcion=
@PSDESCRIPCION,plBloqueado= @PLBLOQUEADO,poCategoria= @POCATEGORIA,poUnidad=
@POUNIDAD,
poProveedor= @POPROVEEDOR,poBodega= @POBODEGA,psComentario=
@PSCOMENTARIO, pbExistenciaReal= @PBEXISTENCIAREAL,
pbExistenciaMin= @PBEXISTENCIAMIN ,pbVolumen=
@PBVOLUMEN,pbCostoUnidad= @PBCOSTOUNIDAD , psEmpaquetado= @PSEMPAQUETADO
WHERE psCodigo= @PSCODIGO
END
IF @MODO=3
BEGIN ---- elimina articulos
DELETE FROM Articulos WHERE psCodigo= @PSCODIGO
END
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH

Sin embargo muchos podrían decir es lo mismo solo que lo unifico, pues para la base
de datos sí, pero el script hace que la base de datos sea pesada únicamente por los
datos, sin olvidar que cuando los llamemos al código del lenguaje que implementemos
será mejor, porque solo necesitaremos llamar un procedimiento. Hay que acotar que
las bases de datos son muy rápidas y más eficientes que el código, para la base de
datos no va a representar mayos dificultad que lo normal. La solicitud se hará en
segundos y para uno como programador representara menos tiempo y menor
desarrollo de código.
Ahora dos detalles más para ejecutar lo anterior usamos lo siguiente:

6
---------------ejecuta el procedure
EXEC sp_IMEARTICULO
1,"DE","BLOQUEO","CATE","UNI","PRO","BODE","COMEN",4,2,10,200,30,"20"
Go

Y para el consultar lo implementaríamos de la siguiente manera:

alter PROCEDURE SP_CARTICULO @MODO int,@PSCODIGO VARCHAR(100)


AS
BEGIN TRY
BEGIN TRAN
IF @MODO=4
BEGIN ----- selecciona un articulo
SELECT A.psCodigo, A.psDescripcion,
A.plBloqueado,A.poCategoria,A.poUnidad,A.poProveedor,A.poBodega,A.psComentario,A
.pbExistenciaReal,
A.pbExistenciaMin, A.pbVolumen, A.pbCostoUnidad,
A.psEmpaquetado
FROM Articulos A
WHERE A.psCodigo=@PSCODIGO
END
IF @MODO=5
BEGIN ----- selecciona todos los articulos
SELECT A.psCodigo, A.psDescripcion,
A.plBloqueado,A.poCategoria,A.poUnidad,A.poProveedor,A.poBodega,A.psComentario,A
.pbExistenciaReal,
A.pbExistenciaMin, A.pbVolumen, A.pbCostoUnidad,
A.psEmpaquetado
FROM Articulos A
END
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH

De esta manera podemos hacer una consulta específica y otra de todos los datos. Así
al igual que el procedimiento anterior solo debemos llamar a un solo procedimiento
para ejecutar varias solicitudes. Y de igual forma se ejecuta de la siguiente manera:

exec SP_CARTICULO 4,"DE"


go

1.5 Conclusiones

Es sorprendente ver que la forma que uno hace las cosas no siempre es la mejor y la
más ideal, también existen mejores formas de implementar los diferentes problemas
que se le pueden presentar, aun así existe la posibilidad de que exista mejores formas
de poder realizar las diferentes implementaciones.
No obstante uno como desarrollador siempre debe de buscar la mejor forma de hacer
o implementar una solución, esto porque un sistema que maneje grandes sumas de
datos la eficiencia y la exactitud favorece contra el tiempo, sin olvidar que nosotros
estamos entregando un sistema de calidad.

7
1.6 Recomendaciones

Para la cátedra este tipo de actividades son muy enriquecedoras y su implementación


lleva a un nivel mayos con respecto a años anteriores.
Para los compañeros este tipo de oportunidades donde uno pueda aprender y
demostrar las capacidades implican un nivel de compromiso y profesionalismo mayor,
así podremos dar lo mejor de nosotros y ver de lo que somos capases.

You might also like