Wątek przeniesiony 2021-04-23 22:59 z Java przez furious programming.

Ocena bazy danych i wzorzec projektowy

0

Jak rozumiem w aplikacji będę posiadał interfejs klasa z podstawowymi metodami np. finalPrice(). Interfejs ten, będą rozszerzać dane klasy produktów np. telefon z dodatkowymi polami. Telefon rozszerzy telefon stacjonarny i domowy i każda z tych klas będzie miała swoje specyfikację.

Teraz pytanie jak rozwiązać problem powielania produktów np. smartfon xyz zielony albo niebieski, z tym że zielony kosztuje 20zł drożej. W polu specyfikacja dodać specyfikację dodatkowa cena np. 20zł i w aplikacji obliczać cenę od głównej? Jeżeli tak, to jak obliczać promocję np. na kolor niebieski tylko. W aplikacji pobiorę kolor zielony i niebieski, ale nie będę wiedział do którego przynależy promocja.

Czy faktycznie nie bawić się i tworzyć za każdym razem produkt, choćby miał on się powielić w 99%. Ułatwia to zarządzanie historią.

2021-04-24_225450.png

0
TomRZ napisał(a):
MuadibAtrides napisał(a):

Description i product details to dla mnie powinna być jedna szeroka tabela, nie widzę osobiście zysku z rozbicia.

Jesteś pewien?

Co w sytuacji kiedy masz w sklepie setki tysięcy produktów, z setek różnych branż? Musiałbyś mieć tabelę z ponad tysiącem kolumn, żeby te wszystkie cechy uwzględnić. LOL

@TomRZ popraw mnie jeśli się mylę, ale według diagramu rozumiem, że zakładamy, że każdy produkt może mieć N wariantów i każdy wariant ma swój opis i detale - bo tak wynika z poprowadzenia linii w 1 poscie. Chyba, że tutaj jest błąd i ten opis przez product id powinien być połączony z głównym produktem?

Czy źle rozumiem details i defacto yo generyczne atrybuty do produktu per wiersz?

2

@brus97: ja u siebie to tak zrobiłem że po prostu grupuję wybrane produkty, które różnią się jedynie cechą X, wg. różnic tej cechy.

Może to być kolor, długość, cokolwiek z cech które są zdefiniowane w specification.

Dla każdego produktu osobno tworzysz listę cech, nawet jeżeli się powtarzają, robienie jakichś algorytmów i rozwiązań żeby zaoszczędzić trochę miejsca generalnie się nie opłaca.

Tworzysz sobie np. relację "product_specifcation_group": id, specification_id, gdzie określasz cechę do grupowania, a potem relację gdzie będziesz miał product_specifcation_group_id oraz product_id - i w ten sposób możesz zgrupować np. 8 prouktów a potem system w sklepie powinien pozwalać na szybkie przechodzenie między wariantami wg. specification_id

Co do reszty to nie patrzyłem już na diagram bo późno, może w poniedziałek.

@MuadibAtrides:
Tak, i Ty byś chciał to zrealizować dodając za każdym razem nową kolumnę do relacji na produkty, kiedy trzeba dodać jakąś nową cechę?

Np. zaczęliśmy sprzedawać pralki i trzeba określić np. prędkość wirowania, więc dodajesz na to nową kolumnę do relacji na produkty?

Nie tędy droga, to byłaby jakaś masakra.

1

Witam serdecznie, poprawiona baza danych mi się podoba dodałbym jednak kluczowe elementy dla sklepu to znaczy wartość podatku. (jest to konieczne) i zastanowiłbym się nad dodaniem
cen sprzedaży oraz zakupu. Ponieważ mają ceny sprzedaży oraz zakupu później w łatwy sposób z CSV wygenerujesz zysk per każde zamówienie. Do tego doliczasz inne koszta i możesz dosyć łatwo rozliczyć się. (Szczególnie ważne w modelu dropshippingu) gdzie nie posiadasz produktów własnych i faktur na masowe zamówienia a setki bądź tysiące pojedynczych.

0

@TomRZ: ja w NoSQL siedzę i tam to co Ty tutaj proponujesz zrobić na relacji przez nowe wiersze robi się po prostu structem / tablicą w encji. Ja bym dążył do jak najmniejszej liczby tabel i jeśli ma to sens złączał w 1 szersze tabele tam gdzie można.

1

@MuadibAtrides: autor pyta o bazę relacyjną a nie NoSQL, nie wiem czy tutaj kogoś interesuje jak Ty byś to zrobił w bazie nierelacyjnej - mnie to nie obchodzi.

0

Hej, sorka za przestój, plusiki rozdałem, tutaj ostateczna wersja bazy danych (dodane rzeczy od Emila). Resztę będę poprawiał w trakcie tworzenia stronki.

@TomRZ Z grupowaniem jeszcze przemyślę potem :d

Jeszcze ostateczne pytanie, lepiej zostawić tabelę status i payment, czy zrobić ich jako enum po stronie aplikacji i wrzucić pola do order.

2021-05-07_222418.png

0

@TomRZ, wytłumaczyłbyś raz jeszcze, bo czegoś nie zrozumiałem. Każdy produkt ma zestaw specyfikacji, które określa logika aplikacji, na podstawie klasy produktu. W takim razie po co nam kategoria, skoro to samo robi klasa?

Ja to rozumiem tak:

  1. Mam produkt, smartfon.
  2. Logika aplikacji na podstawie kategorii pozwala utworzyć smartfon z danymi polami specyfikacji.

Innym razem mam monitor led. Jego kategoria to monitory, monitory led. Robię te same kroki co ze smartfonem. W takim razie co określa klasa produktu?

2

Produkt ma określoną klasę - tylko jedną, natomiast może należeć do wielu kategorii.

Możesz mieć np. damską suszarkę do włosów i wtedy:

  • ma klasę "suszarki"
  • należy np. do kategorii:
  1. AGD
  2. AGD->DO ŁAZIENKI
  3. AGD->DO ŁAZIENKI->SUSZARKI
  4. PRODUKTY WG. PŁCI
  5. PRODUKTY WG. PŁCI -> DAMSKIE

każda z tych 5-ciu kategorii to osobna kategoria - jeżeli robimy je rekurencyjnie w strukturze drzewa.

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