Projekt bazy danych - połączenie 3 kolumn


(si@tk@rz) #1

fragment bazy wygląda w ten sposób:

przechwytywanielw.jpg

Robiąc zamówienia klient będzie wybierał sobie danie z produktów jakie on sobie życzy, tzn. chce ziemniaki; kieszeń z pieczarkami; surówka z marchewki.

To on widzi produkty i zaznacza sobie każdego z osobna, nie jest tak że wybiera zestaw. I czy w sposób jaki przedstawiłem bazę będzie najbardziej optymalnie?

tabela zamowienia pokazuje klienta, ewentualnie sam stolik gdzie dane zamówienie ma zostać podane. W tabeli "danie" umieszczamy produkt wybrany przez klienta (wygenerował on wcześniej w tabeli zamówienia "zamowienie_id". I każdy produkt umieszczamy w tabeli "danie" z powiązanym, tym samym, numerem zamówienia. Macie lepszy pomysł?


(Tomek Matz) #2

Tabele są OK (tzn. zależności między nimi). Będziesz musiał tylko dodać do tabeli danie kolumnę Ilosc. Podobnie do tabeli produkty, bo musisz sprecyzować, czy np. cena jest za 100g jakiegoś mięsa, czy też np. za 1 sok. To się później przyda, gdy będziesz obliczał wartość zamówienia. Można by też pomyśleć, czy nie da się produktów podzielić na kategorie.


(si@tk@rz) #3

te tabele to dopiero ich zarys, dodaję kolejne kolumny, ale dobry pomysł to kategorie, który znacznie ułatwi później wyszukiwanie i przedstawianie klientom menu


(Tomek Matz) #4

Skoro to jest na razie tylko zarys, to możesz zmienić sposób nazewnictwa. IMO lepiej używać liczby pojedynczej nazywając tabelę, czyli powinno być Zamowienie, Produkt, Danie. I w nazwach kolumn warto stosować przedrostki, czyli np. Z_ID zamiast Zamowienie_ID, Z_StatusRealizacji zamiast status_realizacji. Przedrostki mogą mieć więcej niż jedną literę (najlepiej 3). W tabeli Danie miałbyś wówczas D_Z_ID zamiast zamowienie_id oraz D_P_ID zamiast produkt_id, a w tabeli Produkt miałbyś P_ID, P_Cena, P_Opis, P_Dostepnosc. Przedrostki wybieraj takie, żeby łatwo było Ci rozróżnić tabele. No i oczywiście przedrostki muszą być unikalne, tzn. dwie różne tabele nie mogą mieć tego samego przedrostka.


(si@tk@rz) #5

zdecydowanie lepiej będzie używać liczby pojedynczej w nazwach tabel, jednak zważając na to że dostęp do bazy danych będę chciał zrobić przez klasy, to wówczas przedrostki mogą mi utrudnić sytuację, ponieważ np. zmieniając w tabeli klienci napiszę:

$tab = new Klient();

$tab->setImie('Jan'); //$tab->setK_imie('Jan');

Wydaje mi się że łatwiej jest pisać bez przedrostków


(Tomek Matz) #6

Tzn. się czy zdecydowanie lepiej to nie wiem. Ja po prostu tak lubię, bo wydaje mi się to estetyczne. Konwencji nazewnictwa jest dość sporo i to już od Ciebie zależy, na które rozwiązanie się zdecydujesz. Ale gdy już jakiejś wybierzesz to trzymaj się go w obrębie całego projektu struktury bazy danych, bo inaczej zrobi się bałagan.


(si@tk@rz) #7

najlepiej sobie wyrobić sposób nazewnictwa i w każdym projekcie go stosować, wówczas wyrobi się styl i łatwo będzie się poruszać po projekcie. Oczywiście trzeba się trzymać pewnych standardów, bo jak ktoś usiadłby przy moim projekcie, a ja robiąc go używałbym dosłownie własnego stylu to współczuję


(somekind) #8

Ta obfuskacja to jakiś sposób zabezpieczenia bazy przed hakerami? Bo po co innego te przedrostki?


(Tomek Matz) #9

Haha nie :slight_smile: Tak jak pisałem, wydaje mi się, że wtedy jest to wszystko bardziej przejrzyste. Przykładowo w złożonych zapytaniach SQL łatwiej można się zorientować, z której tabeli pochodzi dana kolumna. Czyli tylko estetyka. Innych przesłanek ku temu nie ma.


(somekind) #10

Ja uważam, że nazwa kolumny powinna jasno określać jakie dane są w tej kolumnie zapisywane, analogicznie jak nazwy zmiennych w kodzie programuu. Nie rozumiem tej idei prefiksów - przecież odwoływać do kolumn można się przez nazwa_tabeli.nazwa_kolumny, ewentualnie użyć nawiasów i wszystko jest jasne.


(Fordmtonly) #11

Czy tych zamówień będzie dużo ? Czy interesują Cię dane historyczne czy też zamówienia z danego dnia będziesz czyścił co dzień ? Czy optymalizacja miejsca w bazie jest dla Ciebie istotna ?


(si@tk@rz) #12

zamówienia nie będą czyszczone co dzień, będą przechowywane wszystkie. Będzie można sobie wygenerować średnią zamówień na dzień itp. Obecnie baza wygląda w ten sposób:

przechwytywaniefr.png


(somekind) #13

1) Co to jest za tabela "password" i dlaczego jako jedyna ma angielską nazwę?

2) Co to jest za tabela "adres_inny"?

3) A może zrobić tabelę Adresy i zapisywać w niej zarówno adresy Klientów jak i Pracowników? Zestaw kolumn o tych samych nazwach w trzech tabelach trochę dziwnie wygląda.

4) Kod pocztowy ma zawsze 6 znaków, więc nie trzeba używać typu varchar, wystarczy char.

5) Ogólnie w adresie dobrze przechowywać: ulicę/wieś, numer budynku, numer lokalu, miejscowość/pocztę, kod pocztowy. U Ciebie jest to bardzo uproszczone.

6) Imiona i nazwiska mogą zawierać znaki diakrytyczne, więc typ nvarchar a nie varchar.

7) Dlaczego w "stolik" jest "klient_id"? Czy nie wystarczy relacja klienta do zamówienia i zamówienia do "stolika"?

8) Co to jest danie_prod? Nie powinno być tam czasem kolumny "nazwa" albo podobnej?

9) Do cen nie używa się raczej typów double (zmiennoprzecinkowych). Bezpieczniej jest użyć typu stałoprzecinkowego.

10) "Danie" wygląda jak powiązanie iluś jednostek produktów z zamówieniem. Czyli np. danie to 10 szt. ziemniaków, ziemniaki z kotletem to już dwa różne dania. Chyba nie tak jest w rzeczywistości. Wydaje mi się, że to co nazywasz "danie_prod" to potrawa, a to co nazywasz "danie" to tak naprawdę pozycja zamówienia.

11) Czy dania/potrawy nie powinny mieć jakiejś nazwy?


(Fordmtonly) #14

W sumie nie napisał jaki ma character set bazy. Może ma UTFa.


(Tomek Matz) #15

W Twoim diagramie uwzględniłem pomysły somekind, dodałem swoje i powstało coś takiego:

Mały rozmiar

Duży rozmiar

Oczywiście to wciąż jest do przemyślenia, więc krytyka mile widziana.

EDIT: Wrzuciłem rysunek, bo stwierdziłem, że wyjdzie mi to szybciej niż opisywanie, co mi nie pasuje, ale jedną rzecz skomentuję. Do tabeli ZamowieniePozycja dodałem kolumnę cena (wcześniej o tym nie pomyślałem). To dlatego, że w miarę upływu czasu ceny produktów mogą ulegać zmianie. Gdybyś zmienił cenę w tabeli Produkt to utraciłbyś część informacji o wcześniejszych zamówieniach, np. jaka była wartość jakiegoś tam zamawianego produktu.


(somekind) #16

Nie napisał jaki ma SZBD, a np. w najfajniejszym jest oddzielny typ na napisy w Unicode. Ale pewno masz rację.

Ładnie to tak odwalać za kogoś czarną robotę? :wink:


(si@tk@rz) #17

dzielenie na tabelę o dwóch kolumnach: id oraz nazwa - ma sens? Nie powinno się unikać atomowości?

-- Dodane 07.04.2011 (Cz) 21:13 --

matzu - dzięki za pomoc

Masz rację, ale jeśli Ktoś potrafi w ten sposób pomóc to ja nie mam nic przeciwko:) Tobie również dzięki


(Tomek Matz) #18

Nie no, bez przesady. Zdecydowana większość była gotowa.

W tym wypadku ma to sens. To są tzw. słowniki. Ale jak wolisz to możesz użyć tego typu enum zamiast tych dodatkowych tabelek. Ja ten diagram wykonywałem przy użyciu MS SQL Server. Tam nie ma czegoś takiego jak MySQL-owy enum i w sumie nie wiem, czy jest jakiś jego odpowiednik.

PS Jak zauważycie, że coś jest nie tak w tych tabelkach to piszcie.


(somekind) #19

O jaką atomowość Ci chodzi?


(si@tk@rz) #20

Zrobiłem to tak: przechwytywanieqy.jpg