Jak zaprojektować bazę danych dot. zamówień

0

Witam, mam pytanie podczas tworzenia bazy danych 3 tabele główne tabele (pomine reszte paradygmatów i przedstawie tylko problem):

  • Uzytkownik 1 do wielu Zamowien
  • Zamowienia wiele do 1 Uzytkownik
  • Produkty wiele do 1 Zamowienia
    Podczas samego zamówienia jest w porządku, ale myśląc już o takich rzeczach jak np. wyświetlanie produktów na stronie nie do końca wiem jak to powinno wyglądać stworzyć osobną tabele która nie łączy się z żadnymi powższymi i za pomocą niej wyświetlać produkty i/lub zrobić tylko referencje z tabeli produktów do tabeli która nie jest powiązana z żadną? Może stworzyć 2gą baze danych w której będą przechowywane tylko i wyłącznie książki i informacje o nich? Zapewne problem dość prosty, ale nie wiem jak to powinno wyglądać podczas tworzenia jakiegoś sklepu internetowego. Proszę o pomoc :)
0

Witam ponownie, problem został częściowo rozwiązany - dopiero jak wszystko rozpisałem.

0

Czy mniej więcej taka baza danych oczywiście bez zmiennych była by w porządku? W tabeli AllProducts były by wszystkie produkty które były by wyciągane w razie potrzeby i możliwość dodania ich do tabeli products?

0

1.Idąc Twoim tokiem rozumowania, skoro tabela zawierająca wszystkie produkty nazywa się allproducts, czy tabela z wszystkimi zamówieniami nie powinna się nazywać allorders? A tabela z wszystkimi użytkownikami allusers? (oczywiście nie - pokazuję jedynie niekonsekwencję w Twoim nazewnictwie.)
2.Twoja tabela products dotyczy produktów tylko w zamówieniach, zatem powinna się nazywać order_product i mieć pola order_id, product_id, product_price (bo cena, po jakiej produkt został sprzedany, może być różna od tej, w jakiej jest obecnie) etc.
3.Tabela allproducts powinna się po prostu nazywać product i mieć kolumny product_id, product_name etc., bez żadnego idproducts (w jakim celu ono istnieje?).
4.Tabela orders powinna nazywać się order i mieć kolumny order_id, user_id, order_grand_total etc.
5.Tabela users powinna nazywać się user i mieć kolumny user_id, user_name, user_mail etc.
6.Tabela payments powinna nazywać się order_payment i mieć kolumny payment_id, order_id, payment_value_cash etc.

Oczywiście możesz woleć inny sposób nazewnictwa - ja prezentuję powyższy, ponieważ jest imho bardzo czytelny oraz wygodny:
1.Nazywanie tabel rzeczownikami w liczbie pojedynczej, przez co nie ma potem tabel nazwanych w stylu orders_products, co mnie kłuje w oczy :-P
2.Wykorzystywanie pełnych nazw kolumn nie tylko dla kluczy podstawowych (czyli nie tylko np. user_id, ale także user_name, user_mail), co sprawia, że zapytanie jest łatwiejsze do analizy.
3.Preferuję user_id ponad iduser, ponieważ w drugim przypadku wypadałoby także - trzymając się konwencji - utworzyć kolumny nameuser, mailuser, co wygląda na wymysł jakiegoś niedzielnego programisty.

0

Przepraszam za chaotyczne wypowiedźi, oczywiście we wszystkim masz rację. Poniżej jest moja baza danych. Zastanawiam się tylko czy w tabeli order - codes i payments nie powinny być w osobnej tabeli.

Jeżeli dobrze zrozumiałem to właśnie tak to powinno wyglądać? W momencie kiedy chcemy jakąś tabele z której będziemy wyciągać dane (lub)a zaraz potem przedstawiać je wizualnie na stronie powinny dostać osobną tabele i w razie konieczności połączyć je z tabelami które potrzebują do nich dostęp poprzez inne tabele, tak :)?

Przedstawie jeszcze ogólne przeznaczenie bazy. Zacząłem naukę Springa i jestem właśnie na etapie planowania projektu sklepu internetowego. Czy taka baza będzie pasowała do zwykłego sklepu internetowego z książkami?
W projekcie chce zrobić logowanie użytkowników na koncie użytkownika będą wyświetlane wszystkie doknane transakcje i książki które zakupił(oraz cyfrowy dostęp do nich), menu z kategoriami książek, wyświetlanie książek razem z ich obrazkami w danej kategori (osobna strona dla 1 książki na której będe zamieszczał informacje na temat tej konkretnej), możliwość dodawania ich do koszyku - nastepnie kupowania. 2gi (pod projekt) polegałby dla stronie dla adminów którzy mieli by dostęp do strony mogli dodawać - usuwać książki itd (tutaj zastanawiam się czy nie dodać dodatkowego pola w Users (is_admin). Bardzo proszę o zweryfikowanie tego i w razie jakichś braków podrzucić pomysł :D
relations.PNG

0

1.Tabela Pictures dotyczy specyficznie zdjęć produktów, zatem powinna nazywać się Product_pictures (idąc za Twoim nazewnictwem) + usuń Products.picture_id, a w zamian zrób Pictures.product_id (bo jeden produkt może mieć wiele zdjęć, ale jedno zdjęcie nie może być przypisane do wielu produktów).
2.Nie Pictures.type_of_file, tylko Pictures.file_type - generalnie unikaj of.
3.Dlaczego w tabeli Orders masz order_price, lecz już nie np. order_codes, a samo codes?
4.Order.form_of_payment zamień na order_payment_kind, brzmi sensowniej + prawdopodobnie powinno być enumem.
5.Co to jest Orders.codes oraz Orders.forwarding_address? Zwyczajowo tworzy się shipping address oraz billing address.
6.Nie Products.id_product, tylko product_id.
7.Nie Products.cost, tylko Products.price. A najlepiej to price_net, jeśli będziesz się wdawał w kwestie podatkowe ;-)
8.Za co odpowiada tabela Options i dlaczego nie nazywa się User_options, skoro dotyczy opcji użytkowników?
9.Nie Users.name, tylko Users.user_name itd.
10.Utwórz tabelę Categories i do produktu przypisuj id kategorii, a nie jej nazwę.

Btw, możesz się zastanowić nad wykorzystaniem rzeczownika customer zamiast user - w sklepach częściej ten pierwszy się stosuje.

0

Zostawię nazwę usera i dodałem do niego pole is_admin jeżeli jest - dostanie dodatkową zakładkę admin_site na której będzie mógł wykonywać operację na produktach, dodałem też login i password. We wszystkich tabelach dodałem przed polem nazwe tabeli. Dodałem osobną tabele codes która odpowiada za możliwe kody (1 produkt może mieć wiele kodów na zniżke). Usunąłem nie potrzebną tabele opcje.
relations.PNG

0

1.Jak Twoim zdaniem brzmi liczba pojedyncza rzeczownika categories? ;-)
2.Tabela Order_codes jest dziwna. Od kiedy to daje się zniżkę na produkt zamiast na całe zamówienie? Plus nie jest jasne czy code_discount (tak, nie bój się słownika, zamiast zgadywać: rabat to po angielsku discount lub rebate, a nie rabat) oznacza procent od ceny zamówienia czy kwotę zniżki.
3.Już nie Products.categories_categorie_id, tylko Products.category_id wystarczy.
4.Co to jest Products.product_net?
5.Zauważ, że Twój klucz główny w tabeli Product_pictures brzmi product_pictures_id, co jest mylące (ponieważ tak naprawdę chodzi o id pojedynczego obrazka, a nie wielu) - dlatego, jak wspomniałem, preferuję zawsze wykorzystywanie liczby pojedynczej.
6.Adres składa się z nazwy miasta, kodu pocztowego, ulicy itd., podczas gdy Ty pakujesz wszystko do jednego varchara - a co, gdy się okaże, że na przykład musisz wyciągnąć statystyki zamówień z podziałem na kody pocztowe? Miasta? Dlatego znacznie lepiej będzie utworzyć dodatkową tabelę Addresses, a w tabeli Orders kolumny shipping_address_id oraz billing_address_id. Podobnie zresztą w tabeli Users.
7.Opis produktu może być skrajnie długi bądź krótki - dlaczego więc wybrałeś tam typ varchar zamiast text?

0

Screen pod dołem
mam pytanie po dołączeniu tabeli address w tabeli orders dołączyły się id adresu użytkownika to samo jest w codes i orders_products - czy tak powinno być?

relations.PNG

0

Poprawiona wersja :
relations.PNG

0

Już jest prawie ładnie ;-)

1.Nie Products_product_id, tylko samo product_id.
2.Dlaczego Products.product_price_net to varchar?
3.Skoro zapisujesz cenę netto produktu, wypadałoby także dodać kolumnę na rodzaj podatku.
4.Nie Orders.Codes_code_id, tylko prędzej code_id, a najlepiej w ogóle przemyśleć raz jeszcze czy na pewno nie będzie lepiej zamiast samego code wykorzystać np. coupon_code (wszak co to znaczy w ogóle kod zamówienia?)
5.Dlaczego Users.user_age jest varchar? Poza tym zapisuj rok urodzenia i na jego podstawie wyliczaj wiek.
6.Nie product_picture_type_file, tylko product_picture_file_type - przecież type file nawet brzmi paskudnie. Btw, co konkretnie to pole ma reprezentować?
7.Nie Users_user_id, tylko samo user_id.

0

Super :D
File_type będzie odpowiadało rozszerzeniom plików - nie udało mi się znależć lepszej nazwy.
Odnośnie coupon_codes w jaki sposób mógłbym je reprezentować na stronie? Można by dostawać taki unikatowy kod (np. like strony?) i po wpisaniu go podczas zakupów dostawało by się daną zniżkę? A sama tabela coupon_codes miała by wszystkie aktualne kody które można wykorzystywać?
Jeszcze mam pytanie odnośnie "szyfrowania danych" program w back-endzie powinien szyfrowac takie rzeczy jak hasło, login etc i zapisywać w bazie danych żeby potem je pobrać i odszyfrować?
Standardowo poprawiona baza :
relations.PNG

0

Odnośnie coupon_codes w jaki sposób mógłbym je reprezentować na stronie?

Nie rozumiem o co pytasz.

A sama tabela coupon_codes miała by wszystkie aktualne kody które można wykorzystywać?

Tak.

program w back-endzie powinien szyfrowac takie rzeczy jak hasło, login etc

Hasło się hashuje, resztę zostaw na czysto. Po co miałbyś szyfrować cokolwiek? Jeśli ktoś da radę włamać Ci się do bazy danych, prawdopodobnie złamanie zabezpieczeń Twojej strony również nie będzie dla niego problemem ;-)

Ad bazy:
1.Ceny trzymaj w formacie decimal (np. decimal(7,2)), a nie float. Dotyczy to się tak samo kosztów zamówienia, jak i ceny produktu.
2.product_picture_id, a nie picture_id.
3.Trzymając się konwencji, należałoby napisać product_category_id, a nie samo category_id.
4.W adresie wydziel: kraj, kod pocztowy, miasto oraz ulicę. Nie ma co zagłębiać się w tworzenie odrębnej kolumny numer domu.

0

Racja podanie loginu jako przykładu to słaby pomysł, zostanę przy samym haśle.
relations.PNG

1

Tylko pamiętaj: hashowanie, a nie szyfrowanie :-)
Struktura wygląda teraz ok jak na mój gust.

0

Bardzo dziękuję za pomoc, strasznie mi pomogłeś :D

1 użytkowników online, w tym zalogowanych: 0, gości: 1