W jaki sposób utworzyć/połączyć te dwie tabele? Bazy danych phpmyadmin

Question

Witam.

Załóżmy że mam w bazie danych tabelę "ludzie", a w niej kolumny: id, imię, nazwisko, zestaw_jedzenia.

I chciałbym, aby np zestaw "hehe" zawierał w sobie: lody, czekolada, chipsy, lizaki. W jaki sposób to najlepiej zrobić, połączyć? Mam stworzyć drugą tabelę, a w niej coś takiego?

Tylko jak ją połączyć do zestawu danego użytkownika? Bo chyba bez sensu byłoby przypisywanie id danego użytkownika lub nazwy "hehe" do każdego jedzenia z osobna. Nie wiem czy dobrze myślę, dlatego liczę na odpowiedź, jak ktoś ma jakiś pomysł jak to zrobić.

Answer 1

tabela 1: jak Twoja (zawiera person_id)

tabela 2: id_jedzienia, nazwa_jedzenia (zawiera food_id)

tabela 3 (łącząca): person_id, food_id

i potem pobierzesz sobie z tabeli 3 rekordy np. dla person o ID=5 i Ci zwróci wszystkie przypisane do niego jedzenia.

To tak w dużym skrócie, ale na początek niech tak zostanie.

Taka uwaga tylko - nazwy kolumn nazywaj po angielsku i przyjęła się w bazach danych zasada, że tabele to np. persons, czyli liczba mnoga, a pola w tabeli jako liczba pojedyna, np. person_id, person_name itp. Są też dwie szkoły co to dodawania przedrostków dla nazw pól. Ja je stosuję (najczęściej 3-4 znakowe) ponieważ ułatwia to bardziej skomplikowane związania tabel i umożliwia łatwe przeglądanie wszystkich pól w tabeli - i tutaj trzymam zasadę, aby nazwy pól były unikalne w całej bazie. Ale to już kwestia własnych upodobań. Można potem odwoływać się albo do persons.id albo do person_id lub persons.person_id.

Comments

Dzięki za odpowiedź, ale nie rozumiem jak to ma działać. Mam tabelę ludzie, jedzenie i łączącą (polskie nazwy dałem tylko dla przykładu, aby uprościć problem):

 

I co teraz muszę zrobić? W jaki sposób ma np. id_osoby=1 zwrócić mi tę tabelę z jedzeniem?

---

Jest wiele sposobów na rozwiązanie tego problemu, przykładowy dałem na sqlfiddle:

http://sqlfiddle.com/#!9/4da421/30

Wejdź tam sobie i zobacz. Zrobiłem 3 tabele OSOBY, JEDZIENIE i tabelę łączącą osobę z jedzeniem. Następnie dodałem po kilka rekordów i wygenerowałem zapytanie, które zwraca mi dane w następującej postaci: IMIĘ, jedzenie przypisane do imienia rozdzielone przecinkami To tylko przykład prostego złączenia, nie do końca dobrego dla dużych zbiorów danych ale to tak żebyś złapał zasadę.

Pisałem też pełne formy czyli tabela.pole abyś łatwiej się w tym odnalazł. W zależności od tego co chcesz zrobić czasami lepiej np. wyrzucić jedzenie danej osoby w formie oddzielnych rekordów.

Ja stosuję group_concat jeśli jestem pewien co do znaków używanych w polach co pozwala mi nieco łatwiej pobierać dane (generalnie to polecam poczytać też o widokach), a potem w razie czego mogę to sobie podzielić w JS na tablicę jeśli jest taka potrzeba, ale jak wspomniałem - tylko gdy masz pewność, że "separator" nie wystąpi jako wartość danego pola. ale to tak na marginesie tylko Ci pokazałem bo niewiele poradników opisuje tę funkcję, a bywa przydatna. Ten przykład nie zawiera zestawów jedzenia, tylko dla każdej osoby przypisuję pojedynczo dane jedzenie. Spróbuj przeanalizować ten przykład i rozbudować go o dodatkowe tabele i złączenia pozwalające tworzyć zestawy. Jeśli chcesz jakiś porad to najlepiej pracuj na sqlfiddle aby był łatwy podgląd danych.

---

A tutaj: http://sqlfiddle.com/#!9/94867e/1

masz widoczną potęgę widoków na bazie MySQL. Zobacz w build schema że z wcześniejszego zapytania zrobiłem widok i teraz np. w PHP/node itp. dane mogę pobierać sobie z widoku prostym selectem. Nie interesują mnie już żadne złączenia, ba nawet nie interesuje mnie struktura innych tabel. W razie potrzeby mogę robić zmiany na bazie pilnując tylko, aby zawsze widok zawierał takie same dane. Wg mnie super rozwiązanie, ponieważ mam jasno rozdzielone:

złączenia itp. NA BAZIE

pobieranie danych prostymi selectami W APLIKACJI (back-end)

Ale jest też wielu przeciwników widoków więc to już kwestia indywidualna, nie chciałbym wywoływać tutaj burzy o zaletach i wadach widoków.

---

A więc w ten sposób. Dzięki za pomoc i rady. Jeszcze tylko pytanie - czy ten sposób przechowywania danych będzie odpowiedni i wydajny jeżeli użytkowników byłoby, dajmy na to 100, a w jednym zestawie nawet kilkaset słów? Nie byłoby lepiej dać np każdemu użytkownikowi oddzielną tabelę?

---

 Nie byłoby lepiej dać np każdemu użytkownikowi oddzielną tabelę?

Wymaż ten pomysł z pamięci :)

nie patrz na ilość użytkowników. Pamiętaj, że każdy użytkownik może przecież mieć przypisanych kilka zestawów. Teoretycznie możesz powiedzieć, że przecież każdy user ma mieć tylko jeden zestaw, bo np. ten kupuje. Oki, ale możesz dodać w bazie dodatkowe pola np. na dodanie rekordu (czyli zapisanie zestawu) i pole oznaczające 1/0 czy zestaw jest aktywny. W ten sposób łatwo uzyskujesz pełną historię np. zamawianych, przypisywanych zestawów itp. itd. (Warto myśleć zawsze szerzej projektując bazę danych, ale też bez przesady, ale to już osobny temat).

A co do ilości to Twoje 100 np. rekordów to dla MySQL żadne problem. MySQL działa dobrze z tabelami zawierającymi tysiące rekordów. Czasami można spotkać opinie, że MySQL jest wolny, ale często okazuje się, że wina leży w strukturze bazy albo w niezrozumieniu niektórych elementów. Dla przykładu kiedyś spotkałem tabelę, do której były zapisywane logi w ilościach "hurtowych". Ale już odczyt z tej tabeli był na żądanie i wykonywany sporadycznie. Ale ktoś usilnie musiał pozakładać indeksy na tej tabeli, a potem dziwił się, że baza działa wolno, gdy po każdym insercie tabela musiała ponownie indeksować wszystkie rekordy... Nie wspominając już np. o nie przemyślanych full textach itp. 

Także na Twoje potrzeby na pewno MySQL jest oki i nie przejmuj się wielkością bazy. W bardziej rozbudowanych apkach są też inne możliwości optymalizacji bazy, tabel itp. (np. chociażby odpowiednie zarządzanie silnikami itp.) ale to tematy na dalszy etap nauki.

a w jednym zestawie nawet kilkaset słów?

Hmm, co do samej bazy to bym się aż tak nie martwił, ale martwi mnie inna kwestia - czy na pewno dobrze zaprojektowałeś strukturę skoro musisz mieć aż tysiące "pozycji" w zestawie?

Nie mówię, że to na pewno źle, tylko proponuję ponowną analizę. Może warto rozważyć jeszcze jakieś inne poziomy podziału aby bardziej zespolić pewne elementy powtarzające się. Ale to już kwestia indywidualna i nie ma tutaj jakiś gotowych schematów, zawsze trzeba indywidualnie rozważać strukturę bazy i funkcjonalności aplikacji.

Ale na początek możesz zrobić tak jak piszesz aby poćwiczyć sobie MySQL i pracę z wieloma tabelami.

 

Co więcej, proponuję przy tej okazji poczytać o kluczach obcych.