Które rozwiązanie jest poprawne?

1:
ITEM
id, id_typ, nazwa, cena, kod, ilosc, data_dodania itd
//tabela zawiera wiele pól charakteryzujących równocześnie rower i auto, nie chcę ich dublować w AUTO i ROWER
TYP :
id_typ, nazwa
// np:
// 1, auto
// 2, rower

AUTO:
id, ilosc_drzwi, kolor_karoseri

ROWER:
id, ilosc_przezutek, rozmiar_ramy

Dodatkowo w tabelach auto/rower mogą być klucze obce z innych tabel np słownikowych.

Czy może:
2:
ITEM
id, id_auto, id_rower, nazwa, cena, kod, ilosc, data_dodania itd

AUTO:
id_auto, ilosc_drzwi, kolor_karoseri

ROWER:
id_rower, ilosc_przezutek, rozmiar_ramy

W tym przypadku dodanie nowego rodzaju asortymenu skutkuje zmianą ilości kolumn w ITEM.
Gdy id_auto jest wypełnione - id_rower jest null i odwrotnie.

Serdecznie proszę o pomoc. Wszelkie za i przeciw są mile widziane.

Pierwsza opcja. Definitywnie i ostatecznie.

Tylko ja bym to jeszcze inaczej ubrał,

Masz kategorie:

1) Rowery
2) Auta

Kategoria rowery ma cechy, przerzutki, rozmiar ramy, odblaski sraski duperaski itp, to w osobnej tabeli
Kategoria auta też ma jakieś cechy, w tej samej tabeli co rowery, czyli relacja jeden do wielu

Nas?ępnie właśnie tabela item, czyli przechowująca produkty, bez informacji czy należy do kategorii rowery, czy auta,

Na koniuszku jeszcze tabela wiążąca item, czyli przedmiot z kategorią, skąd wiesz że nie chcesz mieć dwóch przedmiotów w dwóch kategoriach?

A może Rowery będą miały podkategorie? I Jeden rower może znaleźć się w dwóch podkategoriach rowerów?

:]

Wielkie dzięki, o to mi chodziło. Według mnie drugie rozwiązanie od początku było bez sensu.
Jednakże sytuacja którą miałem na myśli nie przedstawia sie tam prosto. Może przykład aut i rowerów został źle wybrany.
Mój problem nie dotyczy sklepu z asortymentem w kategoriach lecz danych do których chcemy dobudować własne tabele - np tabele statystyk.
Dostajemy od producenta aut tabelę z danymi i system który na niej operuje i od producenta rowerów to samo, tylko tabelę z inną strukturą.

Nie możemy ingerować w systemy pracujące na AUTA i ROWERY lecz musimy dobudować coś co pozwoli "okiełznać" dane i stworzyć nowy obiekt który może mieć różne typy i może być rozbudowywany.

Czy myślisz że pierwsze rozwiązanie wciąż jest dobre, czy może ktoś zna inne?

Podałem Ci rozwiązanie które normalizuje dane w bazie. Nie ma lepszego.

Wiem, ale nie rozwiązuje to mojego problemu. Czy znów nie wyraziłem sie jasno?
Jeśli dobrze zrozumiałem to tabela z cechami zawiera tyle kolumn ile jest łącznie cech rowerów i aut (?), w większości przypadków spora część jest null. Czy może tabela z cechami jest tylko słownikiem a wartości cech znajdują się w innej tabeli lub tabelach?
Twoje zastosowanie wydaje się trafne wyłącznie gdy cechy są tego samego "typu". Czy cechą na przykład będzie id producenta rowerów? Jest to podstawowa informacja opisująca wyłącznie rower... Jak będzie wyglądało zapytanie pokazujące wszystkie rowery jednego producenta...? Trochę niefajnie.
Czy już rozumiesz w czym rzecz? Czy moża to ja sam się pogmatwałem?

Narysowałbym Ci uml'a ale mi się nie chce także przedstawię Ci tabele i je przeanalizuj. Tylko to będzie pseudo kod.

table product
idProduct auto,
nameProduct vchar,

table category
idCategory auto,
nameCategory vchar,

table productCategory
idProduct int,
idCategory int

table categoryAttribute
idAttribute auto, -- może być ale nie musi być tego, łatwiej jest gdy jest
idCategory int,
attributeName vchar,

table productAttribute
idProduct int,
idAttribute int, -- dlatego jest łatwiej
attributeValue vchar,

Produkt może mieć atrybuty tylko z danej kategorii, można by jeszcze dodać w tabeli productCategory czy dana kategoria jest domyślną kategorią produktu, wtedy można by za zwęzić ilość atrybutów dla produktu. Wtedy np produkt może mieć atrybut przerzutki i wartości 6, 7 i np 8 przerzutek.

Czy teraz rozwiązałem Twój problem? Spróbuj to zaimplementować rozszerzając o swoje wymagania, i jak będziesz miał problem jak co pobrać ( ale pierw spróbuj sam ) to pisz, chętnie Ci pomogę.

Nie chodzi o to że nie wiem jak to zbudować tylko o to że ten system nie jest wydajny.
Przechowywanie idProducenta w polu typu varchar jako klucz obcy do tabeli Producenci i stworzone na tej bazie zapytanie listujące wszystkie produkty producenta - wszystko to odpada jako rozwiązanie przy dużej ilości danych. I może być kilku producentów, producent siodełka, producent przeżutki itd...
A dlaczego varchar a nie text - co gdy atrybut jest opisem ? Wg mnie to jest droga do niktąd, dlatego zaproponowałem w pierwszym poście 2 rozwiązania, z czego pierwsze wydawało mi się lepsze.
Wydaje mi się że trochę bagatelizujesz problem

A gdzie ja coś takiego napisałem?





Czepiasz się pierdół, napisałeś kiedykolwiek jakiś sklep? Co z tego że produktów w nim będzie 10 tys? Albo i 20 tys, wszystkie na raz będziesz wyświetlał, z każdą daną? Ja bagatelizuje? Wątpię, Ty nie znasz się na bazach danych, na normalizacji tabel, chcesz to sobie zrób nawet enum z atrybutami, człowieku wali mnie jak to sobie zrobisz, zesrasz sobie tabele, później będziesz przepisywał na nowo, albo z dumą będziesz brnął w te gówno które napisałeś mecząc się próbując rozszerzyć możliwości.

Także rób co chcesz.

Nie pisałem po to żeby się kłócić i nie jesteś jedynym członkiem tego forum więc wystarczyło po prostu napisać: nie rozumiem, nie wiem, nie mam czasu, nie obchodzi mnie to.
Już od drugiego postu miałem wrażenie że nie czytasz tego co piszę. Struktura o którą pytałem nie odnosi się do sklepu, magazynu, to jest tylko przykład.
Widzę że jesteś "ekspertem" w tworzeniu sklepów do 20 tys produktów - brawo, obyś pogłębiał wiedzę lecz mi chodzi o rzędy miliona krotek.
Zamiast bluzgów chętnie bym usłyszał gdzie w tej bazie którą proponujesz mam przechowywać powiązanie do producentów np siodełka które znajduje się w rowerze i jak łatwo znaleźć wszystkie rowery z siodełkami jednego producenta (UWAGA: to też jest tylko przykład).
Nie podoba mi się to jak traktujesz rozmówców, mogę być skończonym idiotą ale ty jako osoba wykształcona i inteligentna powinieneś mi spokojnie wszystko wyjaśnić albo nie pisać nic.
Przykro mi muszę to zgłosić moderatorowi bo wydaje mi sie że jesteś tu nie po to żeby pomóc, lecz po to żeby wypromować blog lub podbić sobie ego.

Promować bloga nie muszę od tego mam planete.php i jak są jakieś wpisy to ktoś sobie poczyta i lub nie jak ma mnie w otchłani czeluści. Pisząc to:



Zdradziłeś że nawet nie wiesz czym są klucze obce i jak z nich korzystać. Bo to jest proste jak budowa cepa. Napisałem Ci wyżej:



To ciężko pomyśleć że jak ma się producenta to pasuje powiązać jakoś jedno z drugim?

Masz przerzutki? Ok spoko, producentów przerzutek może być tryliardy. Jaka jest relacja? Wiele do wielu, i co należy zrobić? Utworzyć osobną tabelę która będzie łączyć te badziewie.

proszę:

table manufacturer
idManufacturer int,
nameManufacture vchar

table productManufacturer
idProduct int,
idManufacturer int

Możesz przecież mieć produkt całości np od Shimano itp, więc mamy tabele łączącą produkty z producentami.

Możesz mieć produkt, który jest częścią np roweru: hamulce v-brake:

table attributeManufacturer
idAttribute int,
idManufacturer int

no patrz i załatwiłem sprawę, nic nie umiesz. Nawet myśleć logicznie. Zmieszałem Cię z błotem i wali mnie to czy mnie reportniesz czy nie. Jakoś mi na tym nie zależy.


A powiem Ci więcej, produkt może być np złożony, czyli sprzedajesz produkt, który sam składasz z innych produktów które masz na stanie, weź to sobie zaimplementuj cwaniaku za 2 grosze.

Jeszcze raz powtarzam, to nie jest sklep z rowerami, radziłbym spróbować pomyśleć bardziej globalnie.
Wg Twoich wskazówek powinenem stworzyć nową tabelę wiążącą dla każdego z atrybutów który nie będzie wartością samą w sobie lecz kluczem obcym do innej tabeli. Dodatkowo chyba nie zakładasz że jeden element ma dwóch producentów? Wg mnie tylko takie może być tłumaczenie dodatkowej tabeli wiążącej.

Zobaczmy ile tabel wyprodukowałeś:

table product
table category
table productCategory
table categoryAttribute
table productAttribute
table manufacturer
table productManufacturer
table attributeManufacturer

I jak to się ma do mojego problemu:
Mamy dwie tabele zawierające różne i wspólne atrybuty które mają stworzyć nowy obiekt np chcemy zliczać dla nich statystyki lub nadać unikalny kod produktu - nie jesteś pomocny - po prostu zupełnie sie nie rozumiemy.

Nie chce mi się, nudny jesteś. Opisz jaki masz problem albo czekaj aż się sam rozwiąże.

Wystarczy tego - skoro żadna ze stron nie jest w stanie zachowywać się po ludzku, ucinam dyskusję.