Acceso a Datos 14: RAD Aplicado a diseño de Tablas Opciones

[Admin]

Por favor, recuerden que lo que menciono en este sitio o correos es fruto de experiencia personal y del uso de RAD. No es la biblia pero tiene sus bases, aunque ustedes tomen la decision final de si me hacen caso o no. Uno de los principios RAD, es que debe considerarse el criterio del programador como válido, siempre. Y no es cualquier principio, es el primero y fundamento de todo lo demás.

Si ustedes quieren tener un sistema portable, deben de tener tablas que usen nombres de 10 caracteres en Mayusculas, y con inicios diferentes. Un compañero me mandó una base Access 97, que les adjunto en otro correo y que puede consultarse aquí. El objetivo de esta base es llevar un control de quien tiene que equipo de computadora en que sucursales.

Quiero que se fijen que en mi análisis solo me voy a referir a los nombres y no a los tipos de campos, acepto como válido el criterio de tipos, porque pueden haber referencias específicas. También acepto como buenas las relaciones o no que el programador ha hecho, y todo lo que sigue son simplemente comentarios para facilitar la implementación, pero al mismo tiempo, facilita que otros programadores usen el código, y poder usarlo para llevar un control de cualquier equipo, y no solo en la sucursal.

Sugiero que antes de seguir abran la base de Access, o vean la imagen que está al final de este correo/ hoja web,aquí

Tablas en inventario.mdb.............Sugerido
----------------------------------------------------------------------
[*] CAT_EQUIPO...................[*] EQUIPO
[*] CAT_PLANTA...................[*] PLAZA
[*] CAT_PROVEEDORES..............[*] PROV
[*] CAT_USUARIOS.................[*] EMP_PLAZA
[*] MOVIMIENTOS..................[*] MOV_EQUIPO
[*] RECEPCIÓN DE EQUIPO..........[*] REC_EQUIPO

Access Comentarios

Bien

• Muy bien por las mayúsculas
• Muy bien con el prefijo Cat en las tablas.. pero eso es en el código. Si todas empiezan con CAT, el prefijo resulta mucho menos util.
• EXCELENTE las referencias a campos de otras tablas como debe ser, ejemplo, referirnos siempre a USUARIOS como USUA_CVE en lugar de EQUIPO_USUA
• Los nombres son claros. No hay nada tipo EQUI02 EQUI03 .... Todo son Catálogos ABC, pero el largo de 10 es excedido.

Access Mal

• Los acentos. Algunos campos tienen mayúsculas y la tabla recepción lleva acento. No todos los manejadores los soportan, evitarlos y las ñ Tambien.
• USUARIOS como nombre de tabla. Un programador que vea el código puede confundirse porque USUARIOS suele usarse para derechos. EMP_PLAZA Indicaría que esta hablando de empleados de algun lugar, que a su vez reciben los equipos.
• MOVIMIENTOS como nombre de tabla. Muy largo y puede referirse a cualquier cosa. Movimientos de que?
• Los nombres de los campos en varios casos exceden los 10 caracteres. Puede causar problemas si hay que migrar después.

Ajustes menores

• En este caso hay oficinas, no solo plantas. Usar el nombre plaza permite usarlo en entornos comerciales y no solo industriales.
• Proveedores no se llama Proveedores de equipo que sería lo obvio a primera vista, porque así puede controlarse desde clips hasta material de venta.
• Uno de los campos de equipo, se llama MODLEO, para esto sirven los modelos fisicos, podemos detectar errores de dedo mas rapido.

Access Sugerencias

• El programa llevará control de Equipo.. pero podría controlar insumos o lo que sea, sugeriría cambiar Equipo por MATERIAL.
• Si vamos a llevar control de equipos.. porqué no está el campo EQUIP_CVE en movimientos?
• En algunos casos la descripción es DES ( PLANTA_DES ), en otros descrip ( EQUIP_DESCRIP ), y en otro MOV_OBSERV. Sugiero pasar todo a TABLA_DESC.
• Con Nombre pasa lo mismo en PROVE_NOM y USUA_NOMBRE. Por lo menos va a ser mas facil acordarnos de como se llama el campo si unificamos criterios.
• Yo pondría el nombre del contacto en proveedor, y un campo de descripción/comentario en recepción de equipo.
• El nombre de la base, inventarios2, es largo y poco claro. Inv_Equipo sería mas claro creo yo.
• Si se va a mandar equipo de una plaza a otra, en la tabla de movimientos pondría los campos de plaza origen y plaza destino. Obvio que en movimientos en la misma plaza, serian iguales.
• Para simplificarnos la vida, manejaría EQUIP_CVE como autoincremental numérico y unico.

Es muy recomendable trazar en papel o en Data Architect una relación de dependencias de las tablas, para poder ver a simple vista que es que, y que depende de qué. Aqui pego una imagen que tomé del Data Architect, con las relaciones ( le puse el campo de EQUIP a MOVIMIENTOS y quité los acentos). En un manejo mas formal, debería de poner la fecha del modelo, pero por lo general basta con imprimirla y tenerla a la mano.

Si se fijan en la dirección de las flechas todas apuntan en la misma dirección y no se cruzan. Todos pueden saber que depende de que, en este caso PLANTA sería la mayor en jerarquía, y recepción la ultima.

Si alguien desea que veamos algun caso en particular, manden su base de datos o estructura, preferentemente vacia, a webmaster@ojosabiertos.org, y por el espacio no se preocupen, tengo 250 mb en la cuenta de correo.

-----------------------------------
Alfonso Orozco - Mayo 2001
ICQ 41907900

Mensaje modificado por Lux el Apr 8 2009, 08:48 PM