Clarion y SQL (II)

SQL, mySQL, postgreSQL y otros motores
Responder
Avatar de Usuario
Mauricio
Desarrollador de Clarion
Mensajes: 1057
Registrado: Dom Feb 06, 2011 9:34 am
Ubicación: España
Contactar:

Clarion y SQL (II)

Mensaje por Mauricio » Mié Ago 10, 2011 6:40 pm

Antes de empezar a programar debemos diseñar la base de datos, las tablas que la integran, las relaciones entre las mismas, índices, etc. Dado que programamos, básicamente, sistemas de bases de datos relacionales lo más importante es, precisamente, las relaciones. ¿Quién debe encargarse del mantenimiento de las mismas? ¿Clarion o SQL?. Aún cuando Clarion nos permite hacerlo no es la mejor idea y les explico por qué:
Primero, y más importante, no lo hace en forma eficiente. Esto se nota, y mucho, en los updates en cascada, si tenemos tablas grandes las sentencias enviadas por Clarion al motor harán todo más lento. El MS SQL es un sistema cliente-servidor y tenemos que lograr que la mayoría de las transacciones se resuelvan en el lado del servidor.
Segundo, Clarion es demasiado permisivo. Y cuando digo demasiado me quedo corto. Estuve los últimos meses pasando un sistema cuyas relaciones estaban definidas por el lado de Clarion y entre las cosas que me encontré están relaciones entre campos de distintos tipos (en una tabla LONG, en otra DECIMAL), relaciones establecidas por campos no definidos como claves únicas (es decir que podría darse el caso de tener hijos con muchos padres), relaciones cíclicas (algo que MS SQL específicamente no permite). Un muy mal diseño, totalmente de acuerdo en eso, pero que tal vez no hubiese llegado tan lejos si Clarion no fuese tan permisivo.
Tercero, si el día de mañana tenemos que "atacar" la base de datos con otro sistema, es mejor que las relaciones estén definidas en el motor, caso contrario deberíamos volver a definirlas.
Y cuarto, y no menos importante, es mejor que todo esté definido en el motor. Supongamos que, por ejemplo, tenemos una tabla Clientes y otra Facturas, con una relación Uno a Muchos, ambas relacionadas por el campo Código de Cliente (un mal diseño, más adelante veremos por qué). Cuando pensamos que todo está perfecto el usuario nos pide que cambiemos todos los códigos de cliente y le sumemos 1.000.000 (por más ridículo que parezca tuve que hacerlo una vez). Entonces abrimos el SQL Server Studio Management y hacemos:
UPDATE CLIENTES SET Codigo = Codigo + 1000000
GO
UPDATE FACTURAS SET CodigoCliente = CodigoCliente + 1000000
GO


En este caso, no fue tan difícil Pero ¿qué pasa si la tabla CLIENTES está relacionada con 20 tablas más? Tenemos que escribir tantas sentencias como relaciones y si nos olvidamos de una el sistema se vuelve inconsistente.
Sí, en cambio, las relaciones las maneja el motor, con el primer update es suficiente. Mantenemos la integridad referencial y nos podemos ir rápido a tomar unas cervezas o mates o lo que se les ocurra con el tiempo ahorrado.

Bien, ya sabemos que Clarion (ni ningún otro lenguaje) se debe encargar de las relaciones, estas deben residir en el motor y menos problemas para nosotros. Pasamos ahora al lugar de diseño de las tablas. Nuevamente surge la pregunta: ¿las diseño en el motor y luego las importo al dct? ¿O hago el camino inverso, las diseño en Clarion y las exporto al motor? Particularmente me inclino por la primer opción aunque algunos sé que prefieren la segunda y usan el excelente template DCT2SQL de Roberto Artigas.
¿Por qué elijo la primera? En principio el mismo SQL Server Studio Management tiene un editor de diagramas bastante decente, mejor que el Data Modeller de Clarion. Y si no nos gusta ese hay muchos otros, como ModelRight, Dezign, etc. Algunos de pago, otros gratis. Y las opciones de estos últimos son muchísimas más. La desventaja de diseñar en el motor es que el Synchronizer de Clarion tampoco es un gran producto. Muchas veces me ha pasado que sencillamente se cuelga y pierdo horas de trabajo, sobre todo si intento importar muchas tablas al mismo momento. Mi experiencia personal es que es mejor ir importando de a poco, tal vez alguien haya tenido mejores resultados (me gustaría saberlo, como también saber si alguien usa el Data Modeller).

Algo muy importante a tener en cuenta son las claves primarias. Los browses de Clarion no admiten claves duplicadas, de lo contrario podemos tener registros duplicados en la ventana (aunque estos en realidad no existan). En esos casos podemos agregar un Additional Sort Field que nos asegure que el ordenamiento es único. Un ejemplo que se me ocurre es la tabla CLIENTES ordenada por Nombre, admitiendo que puede haber 2 clientes con el mismo nombre. En SQL hay 2 formas de asegurarnos la unicidad de un registro, una es usando campos IDENTITY que se van a ir autonumerando (normalmente de 1 en 1 pero eso es definible) o campos UniqueIdentifier. Estos últimos son importante si tenemos que usar replicación de datos entre servidores. De acuerdo a la definición de la página de SQL, el tipo de datos uniqueidentifier almacena valores binarios de 16 bytes que funcionan como identificadores exclusivos globales (GUID). Un GUID es un número binario exclusivo; ningún otro equipo del mundo generará un duplicado de ese GUID.

Si, por ejemplo, tenemos facturación en distintas sucursales y un gran servidor en casa central, con los GUID nos aseguramos que no tendremos duplicados, algo que sería muy difícil de evitar con los IDENTITY (podríamos, por ejemplo, establecer que en una sucursal los IDENTITY van de 1 a 2.000.000, en otra del 2.000.001 al 4.000.000 y así, pero requiere más trabajo).

Tanto los IDENTITY como los UniqueIdentifier los maneja SQL, NADA de usar claves autonumeradas en Clarion. Antes de la versión 6.1 manejar los IDENTITY era algo complicado desde Clarion pero a partir de allí se avivaron y pusieron el IsIdentity = TRUE como opción para la definición de un campo.

En la próxima vamos a empezar con el diseño de un par de tablas en SQL y cómo llevar eso a Clarion.
Mauricio, básicamente usando Clarion 6.3
www.tdcsoftware.com y www.clarioneros.com/blog


PabloVM
Novato
Mensajes: 19
Registrado: Mar Feb 22, 2011 10:37 pm
Contactar:

Re: Clarion y SQL (II)

Mensaje por PabloVM » Jue Ago 11, 2011 4:26 pm

Mauricio, estoy siguiendo tus post y la verdad que son exelentes!!!. y mas para mi que me estoy iniciando...

Tengo una pregunta para hacer con respecto a esto ultimo.

Cuando definis in IDENTITY en el MSSQL, supongamos q comience en 1 al nro de cliente en el alta de los mismos....que pasa si una estacion de trabajo me levanta un alta (Aun no la grabo) y luego otra estacion me levanta otra alta?. Al NO confirmar la primera estacion no grabo el 1 para el nro de cliente y como se maneja el IDENTITY del motor en estos casos?, para ambos me ofrece el 1? o se va aumentando a medida que se van dando las altas y me tengo que olvidar de este problema?.
Seria facil probarlo pero hablando con otro colega que segun el lo probo el identity no funciona y por eso me recomendar manejar a mano las clave primarias ID

Pregunto esto porque por codigo estoy manejando a mano la numeracion y la verdad q lo tengo que hacer en cada tabla con la clave primaria numero y tengo q estar documentando para no olvidarme...

Gracias
Saludos.-

Pablo

Avatar de Usuario
Mauricio
Desarrollador de Clarion
Mensajes: 1057
Registrado: Dom Feb 06, 2011 9:34 am
Ubicación: España
Contactar:

Re: Clarion y SQL (II)

Mensaje por Mauricio » Jue Ago 11, 2011 5:33 pm

El valor del IDENTITY lo asigna el motor en el momento de la grabación y no antes. Por el lado del dct, al campo IDENTITY (vamos a llamarlo CLI_ID) lo definís como LONG, ReadOnly (esto es importante, para que Clarion no le envíe nada al motor) y le definís la opción IsIdentity = TRUE.
El usuario del sistema NO conoce la existencia de este campo, solo lo usamos nosotros para las relaciones.

Supongamos que tu tabla CLIENTES tiene solo 3 campos:

CLI_ID LONG (readonly, clave única y primaria)
CLI_NUMERO LONG (clave única)
CLI_NOMBRE VARCHAR(50)

Si el número de Cliente es automático o no puede darse el caso que 2 usuarios asignen el mismo número en un alta y que al grabar el segundo de ello se encuentre conque ya existe. En ese caso lo que podés hacer es chequear antes de la llamada al TakeCompleted() si no tenés duplicados y seguir con la grabación o pedirle al usuario que ingrese un nuevo número.
Mauricio, básicamente usando Clarion 6.3
www.tdcsoftware.com y www.clarioneros.com/blog

PabloVM
Novato
Mensajes: 19
Registrado: Mar Feb 22, 2011 10:37 pm
Contactar:

Re: Clarion y SQL (II)

Mensaje por PabloVM » Vie Ago 12, 2011 11:34 am

OK, me quedó claro. Muchas Gracias! ;)


Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado