Propiedades

 

Las propiedades de una entidad son muy importantes de que estén definidas de forma correcta.

Para facilitar el proceso voy a mantener algunas convenciones:

Campos de Control:

• alter table XXX  
• add 
• q_CreateUser int DEFAULT 0 NOT NULL, — codigo de usuario que realizo el insert  
• q_CreateDate datetime DEFAULT getdate() NOT NULL, — fecha en la que se realizo el insert 
• q_UpdateUser int DEFAULT 0 NOT NULL, — codigo del ultimo usuario que hizo update 
• q_UpdateDate datetime DEFAULT getdate() NOT NULL, — fecha del ultimo update
• q_UpdateUtcDate datetime DEFAULT getutcdate() NOT NULL, — fecha UTC del ultimo update
• q_IsDeleted bit DEFAULT 0 NOT NULL, — 1 si el registro esta marcado como elimitado
• q_DeleteUser int DEFAULT 0 NOT NULL, — codigo del usuario que realizo el delete
• q_DeleteDate datetime DEFAULT CONVERT([datetime],(0)) NOT NULL, — fecha del delete logico
• q_IsProtected bit DEFAULT 0 NOT NULL, — 1 si el registro NO debe ser actualizado
• q_IsValid bit DEFAULT 1 NOT NULL, — 1 si el registro es valido 
• q_ValidFrom datetime DEFAULT getdate() NULL, — fecha de inicio de validez del registro 
• q_ValidTo datetime DEFAULT CONVERT([datetime],(999999)) NULL, — fecha final de la validez del registro 
• q_FlowID uniqueidentifier NULL, — ID del PROCESO en que participa este registro 
• q_FlowNodeID uniqueidentifier NULL, — ID del NODO en el PROCESO 
• q_FlowStatusID uniqueidentifier NULL, — ID del ESTADO del registro
• q_AssignedUser int DEFAULT 0 NOT NULL, — codigo de usuario que tiene asignado el registro
• q_AssignedFromDate datetime DEFAULT CONVERT([datetime],(0)) NOT NULL, — fecha de asignacion 
• q_AssignedToDate datetime DEFAULT CONVERT([datetime],(0)) NOT NULL, — fecha de fin de asignacion 
• q_NoteID uniqueidentifier NULL, — ID de la secuencia de notas asignadas al registro 
• q_Version bigint DEFAULT 0 NOT NULL — contador de las ocaciones que fue modificado el registro
• go

 Todas las tablas que contienen información modificable van a tener estos atributos, el q_Version sera parte del siguiente trigger

 

• CREATE TRIGGER t_XXX_upd ON XXX AFTER UPDATE
• AS 
• BEGIN
• SET NOCOUNT ON;
• declare @rId uniqueidentifier;
• declare @version bigint
• select @rId = xxxID, @version = [q_Version] + 1 from inserted;
• update XXX 
• set [q_Version] = @version
• where xxxID = @rId 
• END
• go

Para los ORM como Telerik ORM, es rapido el mantener los registros de la base de datos sin bloquo y utilizer el campo q_version para verificar si ha sido modificado desde la ultima ves que la leimos, el trigger modifica el campo, entonces si un Usuario modifica el registro es suficiente con verificar el valor de q_version y modificar si es igual, dar un mensaje de error si son diferentes.

Algo que aprendi es que todos los campos pueden ser modificados, de echo el único campo que no puede ser modificado es la fecha de nacimiento, el resto como estado civil y sexo, pueden cambiar. Otro punto importante es que al cambiar no se puede eliminar los valores anteriores. Tomando el ejemplo del sexo:es importante la fecha desde y hasta, porque necesitariamos la fechas para calcular los beneficios sociales de acuerdo con la fecha de cambio.

 

El ejemplo es algo extremo pero es una realidad, en un ERP todo proceso debe ser repetible y si la fecha de emision del reporte se repite, debería generar la misma información, esto tiene varias implicaciones en la forma de almacenar y utilizar la información. Es necesario el tener toda la información rastreable y auditable.

Hay entidades que tiene códigos no modificables como el codigo de agrupación de productos, pero el producto en si, puede tener cambios a lo largo de la vida del producto, y vamos a necesitar tener la posibilidad de cambiarlo sin perder el historial y las relaciones.

En las entidades que el codigo es estatico, utilizare Nchar() o Nvarchar() como clave primaria, esto significa que NO se podra realizar un update a la clave primaria, pero en el resto de entidades, utilizare un GUID como clave primaria y el codigo sera un indice unico, modificable.

Otro punto importante, debe ser posible el realizar un «undo» de los cambios a un registro, la unica forma que es factible es teniendo un log detallado de los cambios realizados, asi se puede retroceder a los valores previos al update. Este retroceder podría implicar el realizar un Nuevo update con los valores previos. Y debe mantenerse la integridad administrativa al realizar el retroceso. Hay un caso que muestra la complejidad de este requerimiento: Si hay la politica de prestar a los empleados hasta el 25% del sueldo, si se modifca el sueldo a un valor superopr, se obtiene un credito por el 25% del Nuevo sueldo y luego se retrocede al sualdo anterior, este cambio tiene una afectación no solo informatica sino legal y administrativa.