Tomas, Lo primero que te diría es que el nombre del Id debe ser distinto en cada tabla, ya que cuando migres a una base de datos van a existir las foreign key y si cada id tiene su propio nombre te va a ser mas facil identificarlas.
De esta forma en Area, tendrias IdArea, Area y este IdArea estaría también en Ordenes... Otro tema, si bien podes poner cualquier nombre a los campos hay criterios bien definidos que puedes adoptar. http://msdn.microsoft.com/es-ar/library/cc467550(v=vs.71).aspx http://msdn.microsoft.com/es-es/library/x2dbyw72(v=vs.71).aspx Fijate que el mayusculas minusculas Pascal y el mayusculas minusculas Camel son los mas usados y los mas convenientes para concatenar palabras en un nombre.... Y para que veas que no solo de Microsot vive el hombre... http://es.softuses.com/181599 Saludos, Pancho Cordoba El 21 de marzo de 2013 18:10, Tomás Corrales Lemoine < [email protected]> escribió: > Hola, colegas. He creado la siguiente estructura de una Base de Datos para > el control de la elaboración de productos comestibles:**** > > **** > > **· **La tabla USUARIOS es para el control de acceso.**** > > **· **La tabla UNIDADES contiene las diferentes unidades de > medida (unidades, gramos, litros, etc.).**** > > **· **La tabla AREAS define las diferentes áreas de elaboración > (Legumier, Lunch, Cocina Central, etc.).**** > > **· **La tabla DESTINOS define los destinos para los cuales se > elaborarán determinados productos.**** > > **· **La tabla PRODUCTOS incluye a todos los productos que se > elaborarán y los productos que se usarán como materia prima para la > elaboración. Un producto elaborado puede ser un ingrediente (materia prima > de otro producto elaborado, por eso los incluyo en la misma tabla y los > diferencio con el campo lógico *es_elaborado*). Por ejemplo, la sal es un > producto industrial y por eso no requiere ninguna elaboración (* > es_elaborado=.F.*) pero un sándwich de jamón y queso sí es un producto > elaborado (*es_elaborado=.T.*) y uno de sus ingredientes es el pan, el > cual a su vez también es un producto elaborado.**** > > **· **La tabla RECETAS define todas las recetas (ingredientes y > su cantidad) para cada uno de los productos elaborados. Esta tabla tiene > una doble relación con la tabla PRODUCTOS debido a los índices de los > productos elaborados (*id_elabora*) y de los ingredientes (*id_product*).* > *** > > **· **La tabla ORDENES es la que registra todas las solicitudes > de elaboración de productos. Esta tabla contiene una referencia circular en > la relación del campo clave *id* con el campo *id_padre*. Esto se debe a > que, por ejemplo, si el área de elaboración “Lunch” recibe una orden para > fabricar 10 sándwiches de jamón y queso, el sistema debería generar > automáticamente una orden de elaboración de 10 panes para el área de > elaboración “Panadería”, y entonces utilizo el campo *id_padre* en la > orden de elaboración de esos 10 panes para saber que su elaboración se > encuentra subordinada a la elaboración de los 10 sándwiches de jamón y > queso.**** > > Hasta ahora este diseño es lo único que tengo hecho y me gustaría saber la > opinión de ustedes y escuchar sus sugerencias antes de lanzarme a codificar > la interface de usuario. Tengo algunas preguntas:**** > > **1. **¿No hay ninguna dificultad con la doble relación entre las > tablas PRODUCTOS y RECETAS?**** > > **2. **¿No es un problema tener una referencia circular con la > relación entre dos campos de una misma tabla (*id* e *id_padre*)?**** > > **3. **¿Me aconsejan el uso de procedimientos almacenados o esto > sería un problema si decido migrar la Base de Datos a otro formato (MSSQL, > MySQL, Access, …)?**** > > Esperando su acostumbrada atención y con mi eterno agradecimiento por su > colaboración desinteresada.**** > > Ing. Tomás Corrales Lemoine**** > > ** ** >
<<image001.jpg>>
