Co jest nie tak z tym schematem SQL?

Projektuję swoją pierwszą bazę danych dla MySQL, a pomysł polega na tym, że mamy zamówienia, które mogą zawierać wiele różnych elementów. Postanowiłem więc zapisać zamówienie z wszystkimi istotnymi informacjami w jednej tabeli, elementy w innym, a następnie utworzyć trzecią tabelę, w której przechowywany jest każdy zamówiony produkt. Oczywiście za każdym razem, gdy będę musiał podać zamówienie, najpierw będę musiał znaleźć każdy identyfikator OrderedItemsID, dla którego Identyfikator zamówienia jest taki sam, jak ID zamówienia, którego potrzebuję, a następnie dopasować go do elementów.Co jest nie tak z tym schematem SQL?

Teraz, ponieważ jest to mój pierwszy projekt DB, nie jestem wystarczająco arogancki, aby myśleć, że to dobre rozwiązanie, więc zastanawiałem się, czy ktoś zna dobre rozwiązanie tego problemu? Dzięki

obraz jest http://img211.imageshack.us/img211/5575/stackoverflowq.png

Źródło

2010-02-01 Anonymous

To wygląda dobrze, dobra praca dla pierwszego wysiłku :) – rjohnston

dobre! Dobra robota w atrybucie 'PriceAtPurchase'; Podejrzewam, że wielu początkujących popełniłoby błąd zakładając, że "Cena" nie powinna być powielana z "Przedmioty" - jednak, jak słusznie zauważyłeś, nie jest to duplikacja! I; jak zaznacza Russ, podobne może być rozpatrywane pod kątem możliwych atrybutów na obu "Zamówieniach" i "Zamówionych Elementach". Jedyne, co muszę dodać to to, że użycie nowego sztucznego klucza na "OrderedItems" pozostawia ci atrybut, który ma ** NO ** znaczenie, jest ** NIGDY ** odwołany i może prowadzić do aktualizacji anomalii. To kwestia sporna, ale myślę, że widzisz, gdzie stoję. ^^ –

Rozwiązanie to jest w porządku, choć w tabeli zamówień Chciałbym umieścić w łącznej cenie, podatków i wysyłki. W ten sposób nie musisz iść do tabeli OrderItems, aby uzyskać sumy.

dodatkowo, będziesz chciał przechowywać wszystko od pozycji do tabeli orderitem. Obejmuje to nazwę i opis. Powodem jest odpowiedzialność. Jeśli ktoś zmieni nazwę przedmiotu w tabeli, to zasadniczo zmieni to dla potwierdzenia odbioru. i nie chcesz tego robić.

Mówiąc ogólnie, wszystkie informacje w tabelach zamówień nie muszą opierać się na rzeczywistych tabelach pozycji.

Możesz również zrobić to jeszcze dalej, aby dodać adres rozliczeniowy i wysyłki, aby użytkownik, który zmieni to w przyszłości, nie zmieni się w tej konkretnej kolejności.

Źródło

2010-02-01 06:05:40

+1: Doskonała praktyczna porada dotycząca odpowiedzialności. –

Zamierzam założyć, że niezmienne części jego danych, takie jak archiwum paragonów, odbywa się za pomocą nie pokazanej tabeli "PriceSheet"., Argumentowałbym, że dołączanie zamrożonej informacji w losowych innych nieskonsolidowanych miejscach jest złą praktyką. Tworzy nieprawidłowości aktualizacji, których należy unikać. –

@ Russ dziękuję. @ Evan Carroll co do cenników są one generowane w zależności od popytu, więc nie są dokładnie zamrożone, ale raczej płynne, jeśli w ogóle. Z drugiej strony - to interesująca uwaga.Jeśli możesz rzucić link lub dwa, które rozwija się na ten temat, doceniłbym to. –

Nie, konstrukcja jest wystarczająco dobra. Tyle tylko, że Przedmiot nie może mieć powiązanego OrderedItem. (np. zupełnie nowy przedmiot umieszczony w katalogu nie został zamówiony) To samo dotyczy zamówienia (np. zamówienie zostało złożone, ale klient nie zdecydował o szczegółach zamówienia), ale jest mniej prawdopodobne.

Źródło

2010-02-01 06:10:11 shinkou

Co mam na myśli to, że pozycja w tabeli Items może nie mieć żadnego odwołania do tabeli OrderedItems. Podczas gdy wpis w tabeli Orders może nie mieć odniesienia z tabeli OrderedItems, ale jest mniej prawdopodobne. – shinkou

@Shinkou, Twoja sytuacja jest możliwa ... Ale czy możesz wyjaśnić, jak zmienić DB za to ... –

@ Król Nie, nie można go egzekwować w rzeczywistej realizacji DB. (tzn. nic w SQL nie może zrobić) Jest to coś, co robimy w fazie projektowania. Proszę odnieść się do wystąpienia "od zera do wielu" i "od jednego do wielu" (również nazwanego wroną stopy) tutaj: http://www.nearinfinity.com/blogs/lee_richardson/an_entity_relationship_diagram_example.html – shinkou

Dla mnie wygląda dobrze, możesz również porównać swoje tabele z przykładową bazą danych o nazwie Northwind, która jest dostarczana z MS Office i łatwo dostępna do pobrania z Internetu. 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

Źródło

2010-02-01 06:18:59 Ali

dziękuję, wiedziałem, że nie byłem pierwszą osobą, która robi coś takiego. –

Co jest nie tak z tym schematem SQL?

Odpowiedz

Powiązane problemy