Baza danych zawierająca części i ich ilość

Question

Witam!

Pierwszy raz tworzę bardziej ambitny projekt web. Szło mi dobrze aż napotkałem pewien problem. Najpierw próbowałem rozwiązać go sam po 3 godzinach pomyślałem, że może lepiej poszukać czegoś w kursach pana Zelenta po obejrzeniu wszystkich 5 odcinków postanowiłem złapać się mojej ostatniej deski ratunku, czyli Was. 

Zatem problem wygląda następująco:

Mamy 3 dane: id przedmiotu, id części (liczba mnoga) z których jest wykonany oraz ilość każdej z części która jest potrzebna do stworzenia przedmiotu. W jaki sposób skonstruować relację (tabelę) oraz kwerendę która po wprowadzeniu posiadanych przez nas części i ich ilości zwracałaby id przedmiotów które możemy z nich zbudować.

Zastrzeżenie:

• Części potrzebnych do  stworzenia danego przedmiotu jest liczba nieokreślona (odpada więc zapisywanie każdej części w oddzielnym.

Zawczasu dziękuję każdemu kto choć spróbuje mi pomóc.

Answer 1

A gdybyś tak najprościej to zrobił, na etapie nauki bo przy dużych danych to niezbyt wydajny sposób, ale do nauki oki:

tabela przedmioty (
  id
)

tabela czesci (
  id
)

tabela przedmioty_czesci (
  id_przedmiotu,
  id_czesci,
  ilosc_czesci
)

i wtedy miałbyś np. przedmiot X, części A, B, C i w tabeli łączącej np.:

id_przedmiotu	id_czesci	ilosc_czesci
1	5	4
1	8	1
1	20	15

wtedy co prawda może być dużo rekordów dla każdego przedmiotu, zalezy jak jest to złożone. Jesli masz np. 100 przedmiotów i każdy z kilku-kilkunastu części to rozwiązanie może być, ale jeśli będą to mega duże zbiory to trzeba by pomysleć nad innym rozwiązaniem.

Można też przeanalizować ilość powtórzeń jakiś części w przedmiotach i np. zrobić również tabelę zestawy_czesci itp.

Ale powyższy przykład to taka książkowa sytuacja do zrozumienia złączeń w tabelach.

Comments

Z tym jest właśnie mały problem. W ten sposób już robiłem, ale chcę to rozwinąć i dostosować do dużej ilości danych, a nie wiem jak. Kiedy pisałem, że "tworzę bardziej ambitny projekt" chodziło mi głównie o wielkość i ilość danych.

---

a co oznacza duzy zbiór danych, jaka baza, jak dużo części składa sie na przedmiot, ile przedmiotów itp.?

No i to o czym pisałem, czy da się rozważyć jakieś zestawy, kolekcje części i je przypisywać do przedmiotów? Jeśli są to jakieś powtarzalne rzeczy to zostalibyśmy dalej przy tym samym układzie tabeli pośredniej, tylko doszłaby nam tabela zestawy i łącząca części z zestawami.

I pytanie w czym dokładnie jest problem z wydajnością? Jeśli chcesz przyspieszyć same odczyty z bazy to pomyślałym np. nad stworzeniem widoków dla selectów z back-endu, czyli w widoku miałbym już gotowe dane, a te złączenia potraktowałbym np. GROUP_CONCTAT i potem w aplikacji rozbiłym sobie te elementy po jakimś separatorze itp.

Kiedyś robiłem dla kogoś tutaj przykład tworzenia widoków w mysql i mam takie coś w swoich archiwach: http://sqlfiddle.com/#!9/c8a67d7/1

Wtedy odwołujesz się do widoków, a te będą automatycznie aktualizowane po insertach. Jeśli jest znacznie więcej selectów niż insertów to poprawi to wydajność.

---

jak dużo części składa sie na przedmiot, ile przedmiotów itp.?

 Na tym polega problem, że nie wiadomo ile części składa się na przedmiot. Dla jednego przedmiotu może to być jeden, a dla drugiego np. 20.

Chciałbym aby można było do tej bazy "włożyć" ile się chce. Wiem, że zawsze będą jakieś ograniczenia np. sprzętowe, ale na razie chciałbym je pominąć. Chodzi mi o sam schemat.

 

No i to o czym pisałem, czy da się rozważyć jakieś zestawy, kolekcje części i je przypisywać do przedmiotów? Jeśli są to jakieś powtarzalne rzeczy to zostalibyśmy dalej przy tym samym układzie tabeli pośredniej, tylko doszłaby nam tabela zestawy i łącząca części z zestawami.

lista przedmiotów jest przechowywana w innej tabeli, każdemu jest przypisany numer id, w tabeli relacjonującej przedmioty z częściami do opisywania części używany jest ich numer id, więc można zapisać jako int. Nie da się zrobić żadnego zbioru części gdyż zakładam, że użycie którejkolwiek z części nie oznacza potrzeby użycia jakiejś innej

 

I pytanie w czym dokładnie jest problem z wydajnością? Jeśli chcesz przyspieszyć same odczyty z bazy to pomyślałym np. nad stworzeniem widoków dla selectów z back-endu, czyli w widoku miałbym już gotowe dane, a te złączenia potraktowałbym np. GROUP_CONCTAT i potem w aplikacji rozbiłym sobie te elementy po jakimś separatorze itp

Pisząc o dostosowaniu do  większych danych nie chodziło mi o wydajność lecz o wielkość. Chodzi o to, jak wspomniałem wcześniej, by nie dodawać niepotrzebnych kolumn.