¿Qué hay de malo en este esquema de SQL?

Estoy diseñando mi primera base de datos para MySQL y la idea aquí es que tenemos órdenes que pueden contener múltiples elementos diferentes. Así que decidí guardar el pedido con toda la información relevante en una tabla, los artículos en otra y luego crear una tercera tabla donde se almacena cada artículo ordenado. Por supuesto, cada vez que necesite enumerar un pedido, primero tendré que encontrar todos los ID de OrderedItems para los que OrderID es el mismo que el OrderID que necesito y que coincida con los ítems.¿Qué hay de malo en este esquema de SQL?

Ahora, dado que este es mi primer diseño de base de datos, no soy tan arrogante como para pensar que es una buena solución, entonces me preguntaba si alguien sabe una buena solución para este tipo de problema. Gracias imagen

está en http://img211.imageshack.us/img211/5575/stackoverflowq.png

Fuente

2010-02-01 Anonymous

Eso se ve bien, buen trabajo para un primer esfuerzo :) – rjohnston

bueno! Bien hecho en el atributo 'PriceAtPurchase'; Sospecho que muchos principiantes cometerían el error de suponer que 'Price' no debería duplicarse en' Items'; sin embargo, como has notado correctamente, ¡esto no es una duplicación! Y; como señala Russ, se puede considerar un similar para posibles atributos tanto en 'Pedidos' como 'OrderedItems'. Lo único que tengo que añadir es que el uso de una nueva clave artificial en 'OrderedItems' te deja con un atributo que tiene ** NO ** que significa, ** ** NUNCA ** referenciado, y puede llevar a anomalías de actualización. Es un tema polémico, pero creo que ves dónde estoy parado. ^^ –

Esta solución está bien, aunque, en la tabla de órdenes que pondría en un precio total, impuestos y envío. De esta forma, no es necesario que vaya a la tabla OrderItems para obtener los totales.

Además, tendrá que almacenar todo, desde el artículo en la tabla de orden de pedido. Esto incluirá el nombre y la descripción. La razón es para la responsabilidad. Si alguien cambia el nombre de un elemento en la tabla, eso esencialmente lo cambiará para el recibo de todos. y no quieres hacer eso.

dicho básicamente, toda la información en las tablas de pedidos no necesita depender de las tablas de elementos reales.

También puede llevar esto más allá para agregar la dirección de facturación y envío, de modo que si el usuario cambia esto en el futuro no cambiará para este orden específico.

Fuente

2010-02-01 06:05:40

+1: Excelentes consejos prácticos con respecto a la responsabilidad. –

Voy a suponer que las partes inmutables de sus datos, como un archivo de recibos, se realiza a través de la tabla "PriceSheet" no mostrada. Sostendría que adjuntando esa información congelada, al azar en otros lugares no consolidados es mala práctica. Crea anomalías de actualización que deben evitarse. –

@ Russ gracias. @Evan Carroll en cuanto a las hojas de precios, se generan en cierta forma en función de la demanda, por lo que no están exactamente congelados, sino más bien fluidos en todo caso. Por otra parte, es una consideración interesante.Si puede lanzar un enlace o dos que expliquen sobre el tema, lo agradecería. –

No, el diseño es lo suficientemente bueno. Excepto que un artículo no podría tener OrderedItem relacionado. (por ejemplo, es posible que no se haya pedido un nuevo artículo incluido en el catálogo). Lo mismo podría aplicarse al pedido también (por ejemplo, se realizó un pedido, pero el cliente no ha decidido los detalles del pedido), pero es menos probable.

Fuente

2010-02-01 06:10:11 shinkou

Lo que quise decir es que una entrada en la tabla Elementos no puede tener entrada de referencia de la tabla OrderedItems. Mientras que una entrada en la tabla Pedidos puede no tener referencia de la tabla OrderedItems, pero es menos probable. – shinkou

@Shinkou, Su situación es posible ... Pero puede explicar cómo alterar la base de datos para eso ... –

@El Rey No, no se puede aplicar en la implementación real de DB. (es decir, nada en SQL puede hacer) Es algo que hacemos durante la fase de diseño. Consulte el caso "cero a través de muchos" y "uno a través de muchos" (también denominado patas de gallo) aquí: http://www.nearinfinity.com/blogs/lee_richardson/an_entity_relationship_diagram_example.html – shinkou

Me parece bien, por cierto, también puede comparar sus tablas con la base de datos de muestra llamada Northwind, que viene con MS Office y también se puede descargar fácilmente desde Internet. http://www.learn-sql-tutorial.com/Images/relationships.gif

http://msdn.microsoft.com/en-us/library/cc161164.aspx

http://www.microsoft.com/downloadS/details.aspx?FamilyID=c6661372-8dbe-422b-8676-c632d66c529c&displaylang=en

Fuente

2010-02-01 06:18:59 Ali

gracias, sabía que no era la primera persona que hacía algo así. –

¿Qué hay de malo en este esquema de SQL?

Respuesta

Cuestiones relacionadas