Pokaże o co mi chodzi na prostym przykładzie

Mam 2 tabele:
1) Kursy
- id_kursu
- dzialy
2) Dzialy
- id_dzialu
- nazwa_dzialu

Wystepuje tu refernecja dzialy - id_dzialu. Teraz problem polega na tym, ze dzialow moze byc sporo, ale przy tym moze ich nalezec zalozmy 10 do danego kursu. Jak rozwiazać ten problem w MySQL (wiem, że po Oracle występują takie obiekty jak kolekcje). Defakto najprostrzy przyklad tego problemu to np. klient Kowalski w tabeli klienci i referencja adresy do tabeli adresów, ale np. Kowalski ma tych adresów 3. (hipotetyczna sytuacja).

Tworzysz sobie dodatkową tabele, np.
Kursy_Dzialy
- id_dzial
- id_kurs
czyli relacja wiele do wielu.

Mógłbyś jakoś bardziej obrazowo pokazać teraz relacje między tymi trzema tabelami ?

Należałby troche zmodyfikować obydwie tabele, co mogłoby wygladać tak:

Kursy


Dzialy


a tabela łącząca tak:

To jeszcze tylko jak relacje bedą wyglądały ?

A samemu pomyśleć to nie łaska?

O tej godzinie zdaje się na innych ;P

http://forum.php.pl/index.php?showtopic=41274

Nie dawno @kociou1 wysłał na forum posta w którym jest napisane co nieco o baza danyh. Co prawda jeszcze tego nie przeglądałem, ale wydaje mi się, że z cała pewnością przyda Ci się lektura z modelu relacyjnego.

Ewentualnie zapraszam do skorzystania z tego linku: http://db.tigra-system.pl/art.php?id=16

edit:

daleko nie zajdziesz z taką postawą

Postawa ta była czystym żartem. A po drugie model relacyjny względnie znam chodzi mi tu o konkretne rozwiązanie problemu.

Konkretne rozwiązanie zaproponował @spenalzo

Skoro względnie model relacyjny znasz nie powinieneś mieć kłopotów z zdefiniowaniem relacji wiele do wielu i jej zastosowaniem.

Widzisz jakie to bez problemowe, mimo to nie napiszesz tego w paru zdaniach, tylko wysilasz sie na obrazaniu innych uzytkownikow. Slynna niekonkretna pomoc.

Tu masz rozwiązanie problemu, dalsza dyskusja jest zbędna.

http://forum.php.pl/index.php?showtopic=41...=0&#entry229091

Może jeszcze zapytania, kod php i dokumentacje mamy napisać? :roll2:

Mógłbym Ci od ręki napisać kilka stron na temat modelu relacyjnego. Jednak szkoda mojego czasu bym pisał coś co już wiele razy zostało napisane. Wystarczy trochę woli, google i poszukania informacji na ten temat.

Jeżeli chodzi o konkretną pomoc to postarałem się znaleźć linki i dać Ci byś sobie tylko mógł kliknać i poczytać na ten temat. To jest moja konkretna pomoc dla Ciebie. Ale chyba Ci się nie chce z niej skorzystać.

EOT

Pozdrawiam.

Czy ja Cie prosze o to abys od reki wypisywal mi wszystko na temat relacyjnych baz danych. Chce sie tylko dowiedziec jak w praktyce wyglada relacja wiele-do wielu z zastosowaniem tabeli łączącej. Przegladalem te materialy (na ktore jeszcze nie spojzales). Jednak to co tam jest napisane na temat tej relacji to oczywista teoria. Innymi slowy wiem po co to jest ale nigdy nie stosowalem w praktyce a przykladu na 3 byle tabelach z relacjami nie znalazlem.

Relacja wiele do wielu zachodzi wtedy, gdy pojedynczemu rekordowi w tabeli podstawowej odpowiada jeden lub więcej rekordów w tabeli związanej, a pojedynczemu rekordowi w tabeli związanej odpowiada jeden lub więcej rekordów w tabeli podstawowej.

Wyjdźmy od czegoś takiego. Masz dwie tabele powiedzmy: tabela towary oraz zamówienia. W tabeli towary przechowujemy jakieś tam dane dotyczące produtków, które sprzedajemy, np. nazwa, opis, sww,... Masz drugą tabele: zamówienia, w której przechowujesz informacje o zamówieniach produktów przez danych klientów, np. data zamówienia, data realizacji,...

Musisz te dwa obiekty teraz ze sobą połaczyć, przy czym musisz uwzględnić następujący warunek: do jednego zamówienia może być przypisane wiele produktów, natomiast jeden produkt może być przypisany do wielu zamówień.

Wykorzystujesz do tego tzw. tabelę łączącą, w której skład wchodzą klucze podstawowe tabel towary i zamówienia (bo po czymś musimy identyfikować co to są zaproduktu lub jakie zamówienia). Dodatkowo mogę wskład tabeli łączącej wchodzić dodatkowe pola typu cena (by móc określić jaka obowiązywała cena w danym dniu dokonania zamówienia) lub ilość zamówionych towarów.

Na podstawie takiego modelu tworzysz następującą strukturę bazy danych:

[SQL] pobierz, plaintext 
CREATE TABLE TOWARY (
  t_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  nazwa VARCHAR(255) NULL,
  opis TEXT NULL,
  cena DECIMAL(10,2) NULL,
  PRIMARY KEY(t_id)
);
 
CREATE TABLE TOWARY__ZAMOWIENIA (
  t_id INTEGER UNSIGNED NOT NULL,
  z_id INTEGER UNSIGNED NOT NULL,
  cena DECIMAL(10,2) NULL,
  ilosc FLOAT NULL,
  PRIMARY KEY(t_id, z_id),
  INDEX TOWARY_has_ZAMOWIENIA_FKIndex1(t_id),
  INDEX TOWARY_has_ZAMOWIENIA_FKIndex2(z_id)
);
 
CREATE TABLE ZAMOWIENIA (
  z_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  data_zamowienia DATE NULL,
  data_realizacji DATE NULL,
  PRIMARY KEY(z_id)
);
[SQL] pobierz, plaintext 

Teraz już się wyjaśniło - mam nadzieję, że pomogłem.

Pozdrawiam.

No naprawde jestem pod wrażeniem
Dzięki

Praktycznie tabela typu INNODB

A tak dodajesz do tabeli relacje

[SQL] pobierz, plaintext 
ALTER TABLE tabela
  ADD CONSTRAINT fk FOREIGN KEY (idf) REFERENCES tabela_f (pole_f);
[SQL] pobierz, plaintext 

Jak bys nie wiedzial dalej co jak oznacza to juz nie ma rady, wkoncu trzeba otworzyc manual i przeczytac.

--- Dodane ---
@mhs w Twoim przykladzie nie ma relacji

Poczytalem sobie troszke co tutaj wklejaliscie itd;)
Mysle ze koledze chodzi chyba o inna sytuacje a mianowicie tabela przejsciowa przydalaby sie jezeli załózmy mamy 20 rozdziałów i ileś kursow. I te kursy korzystaja z tych rozdziałów w rózny sposób. Jednak jezeli mamy dla kazdego kursu stworzyc nowe rozdzialy tak ze np
Kurs 1 ma Rozdzial 1 Rozdzial 2 Rozdzial 3
a Kurs 2 Rozdzial_kurs2_1 ....... Rozdzial_kurs2_ 10
i zbudowac baze zeby nie bylo nadmiernej ilosci wierszy to jest to problem bez stosowanie typow obiektowych i kolekcji. I mysle ze wlasnie to jest problem kolegi "soniciusa".

@SongoQ - Możesz powiedzieć co masz na myśli dokładnie - chodzi o to, że w DDL'u nie zdefiniowałem CONSTRAINT'a czy coś innego?

witam ...

nie zastosowałeś FOREIGN KEY ... w twoim przykładzie jest to powiązanie o którym programista musi "pamiętać" ... zastosowanie FOREIGN KEY powoduje że część zadań (update, delete) wykonuje baza ... właściwie w twoim przykładzie trzeba tylko zmienić klucze na FOREIGN KEY i będzie git ...

pozdrawiam

Fakt, w powyższym przykładnie może nie tyle zapomniałem co po prostu w DBDesignerze nie zaznaczyłem odpowiednich opcji definiujących założenie kluczy.

Dla pełności dodam, że w takim przypadku do definicji należałoby jeszcze dodać:

[SQL] pobierz, plaintext 
ON DELETE [RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT]
[SQL] pobierz, plaintext 

oraz

[SQL] pobierz, plaintext 
UPDATE RESTRICT [RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT]
[SQL] pobierz, plaintext 

No i oczywiście jak wspomniał @SongoQ w MySQL'u - InnoDB