[color=#FFFFCC]Access Comentarios

[color=#FFFFCC]Bien

1. Muy bien por las mayúsculas
2. 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.
3. EXCELENTE las referencias a campos de otras tablas como debe ser, ejemplo, referirnos siempre a USUARIOS como USUA_CVE en lugar de EQUIPO_USUA
4. Los nombres son claros. No hay nada tipo EQUI02 EQUI03 …. Todo son Catálogos ABC, pero el largo de 10 es excedido.

[color=#FFFFCC]Access Mal

1. Los acentos. Algunos campos tienen mayúsculas y la tabla recepción lleva acento. No todos los manejadores los soportan, evitarlos y las ñ Tambien.
2. 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.
3. MOVIMIENTOS como nombre de tabla. Muy largo y puede referirse a cualquier cosa. Movimientos de que?
4. Los nombres de los campos en varios casos exceden los 10 caracteres. Puede causar problemas si hay que migrar después.

[color=#FFFFCC]Ajustes menores

1. En este caso hay oficinas, no solo plantas. Usar el nombre plaza permite usarlo en entornos comerciales y no solo industriales.
2. 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.
3. Uno de los campos de equipo, se llama MODLEO, para esto sirven los modelos fisicos, podemos detectar errores de dedo mas rapido.

[color=#FFFFCC]Access Sugerencias

1. El programa llevará control de Equipo.. pero podría controlar insumos o lo que sea, sugeriría cambiar Equipo por MATERIAL.
2. Si vamos a llevar control de equipos.. porqué no está el campo EQUIP_CVE en movimientos?
3. 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.
4. 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.
5. Yo pondría el nombre del contacto en proveedor, y un campo de descripción/comentario en recepción de equipo.
6. El nombre de la base, inventarios2, es largo y poco claro. Inv_Equipo sería mas claro creo yo.
7. 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.
8. 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