Zastanawiam się nad sensem korzystania z relacji, jedyną zaletę jaką mogę znaleźć to zmniejszenie rozmiaru bazy co może przełożyć się na większą wydajność.
Ale widzę tu znacznie więcej wad:
-pobranie danych w relacji na pewno jest mnie wydajne "SELECT imiona.imie FROM osoby,imiona WHERE osoby.id = 1 AND osoby.imie_id=imiona.id" VS "SELECT imie FROM osoby WHERE id = 1" musi być szybsze...
-widać też, że zapytanie jest dużo bardziej skomplikowane

Są przypadki gdzie zapisanie danych w relacji wymaga dużo większego obciążenie dysku:
Gdy do bazy chcemy dodać osobę najpierw musimy sprawdzić czy jej imię i nazwisko jest w bazie i pobrać ich id, dopiero w tym momencie możemy dodać osobę. Gorzej jeżeli imienia lub nazwiska nie ma w bazie bo dochodzą kolejne zapytania "INSERT".

Wychodzi więc iż trzeba przemyśleć gdzie relacje będą korzystne, w przypadku powyższym dużo lepiej wykorzystać jedną tabele, chyba, że potrzebujemy listę imion i nazwisk wtedy przy dodawaniu osoby wykonujemy jednocześnie 3 INSERTy gdzie w bazie imion i nazwisk ustawiamy wartości na unikalne.

Trzecia sprawa, czy w bazach, które raczą się zwać relacyjnymi nie ma jakiś narzędzi do upraszczania poleceń pobrania czy dodania rekordu?

Masz na myśli procedury i widoki?


Ale pozostaje problem skalowalności i właśnie wydajności przeszukiwania. Masz np. portal społecznościowy i trzymasz rozbudowane opisy profili. Czy RDBMS szybciej wyszuka rekord w tabeli, w której jest sporo danych wykorzystywanych dość rzadko, czy gdy najpierw wyszuka odpowiednie rekordy i dopiero potem dołączy opisy?


To nie jest problem. Jeśli się wie, co się pisze i odpowiednio to formatuje, to nie jest problem. Tak samo, gdy żyjemy w erze ORM-ów.


A czy kolega słyszał o indeksie UNIQUE i ON DUPLICATE KEY?

No jak ty chcesz tworzyć relacje z imion to nic dziwnego, że nie widzisz w tym sensu.... w tym przypadku to ja też nie widzę sensu

W pełni się zgadzam. Równie dobrze mógłbyś stworzyć tabelę z nazwiskami i tabelę osób zrobić jako id_imienia oraz id_nazwiska. Byłoby to jak najbardziej poprawne z punktu widzenia normalizacji, ale kompletnie bezsensowne z logicznego punktu widzenia.

Relacje i więzy integralności mają tą cechę, że pomagają utrzymać spójność bazy danych. Mając np. tabelę z postami i z kategoriami oraz utworzoną relację baza danych nie pozwoli na przypisanie postu do kategorii, która nie istnieje. Relacjami możesz również wymusić kaskadową aktualizację lub usuwanie rekordów. Jeśli (w powyższym przykładzie) usuniesz daną kategorię to można automatycznie usunąć wpisy z nią powiązane.

@phpion: czemu nielogiczne? A może wyszukiwarka po nazwiskach w jakimś serwisie genealogicznym Kwestia zastosowania relacji jest zawsze przecież płynna i zależna głównie od celu. O ile w większości przypadków masz rację co do bezsensu takiego podziału to będzie pewien odsetek, gdzie będzie to uzasadnione jakąś funkcjonalnością aplikacji, co może się dodatkowo zupełnie nie kłócić z pewną nadmiarowościa w innym miejscu. Czasem sensowne pod względem wydajności jest zastosować podwójne "zakombinowanie". Wprowadzanie danych tekstem dla choćby full text searcha i tabela w MyIsam a dodatkowo na etapie dodawania rekordu jeszcze skrypt bawiłby się z n-n. Sam tak robię w jednej bazie z systemem tagów. mam full text search na pole varchar z wszystkimi tagami artykułu, ale dla wydajności po stronie php mam jeszcze zabawę z relacją typu n-n dla nich. Wyszukiwarka po tagach więc śmiga szybko jak gepard na sterydach, ale i zwykła wyszukiwarka korzysta z tego co ktoś wpisał jako tagi bo jadę na full text searchu złożonym między innymi z tej kolumny. Nie wyobrażam sobie próby zrobienia szybkiej wyszukiwarki po tytule, treści i tagach artykułu, gdybym miał tylko ową relację n-n. UNION ciekawie by musiał wyglądać

Do autora. relacje są baaaardzo przydatne, ponieważ tak naprawdę w świecie wiele rzeczy ma ze sobą powiązania, w ten czy inny sposób. To nad czym powinniśmy jednak jako programiści pomyśleć, to na jakim stopniu złożoności i głębokości tych powiązań powinniśmy powiedziec "Stop! Dalej kombinować i dzielić/separować dane nie ma sensu." a do tego trzeba już doświadczenia i obycia z bazami danych oraz różnymi ich typami by wiedzieć gdzie co ma sens, a co nie i lepiej dac sobie spokój lub użyć innego rozwiązania. Dlatego nadmierna normalizacja jest tak samo bezsensowna jak jej olewanie. Trzeba naprawdę wiedzieć kiedy powiedzieć sobie "Dość". A tego żadna książka Cię nie nauczy tak naprawdę.

Ja dostałem kiedyś od użytkownika z innego forum odpowiedź,że trzy proste kwerendy,są wydatniejsze niż jedna złożona kwerenda.
Nie wiem ,mogę być w błędzie,to są tylko moje dywagacje:- Jedno ,złożone zapytanie, dajmy na to z join lub z podzapytaniami select ,wykonują 2-3(więcej) operacji na bazie ,w tym samym czasie(w zależności od ilości podzapytań) to z logicznego punktu widzenia, wydaje mi się,że obciążenie procesora jak i zużycie pamięci wzrasta,ale mimo to zwracany wynik z takiej złożonej kwerendy będzie wypluwany szybciej niż z 3 osobnych zapytać,ale co jeśli będziemy używać dużo takich złożonych zapytań na stronie-czy to za bardzo nie obciąży procesora lub pamięci przez co w rezultacie nasza strona będzie działać wolniej?
Natomiast 3 proste zapytania-nie powinny obciążać procesora i pamięci,ale czas zwrócenia zapytania będzie zapewne dłuższy.

Poza tym wyczytałem w jednej z książek ,że struktura zaprojektowanej bazy danych jest wówczas dobra,gdy odwołujemy się
do niej poprzez jak najkrótsze i precyzyjne zapytania.

Podsumowując cytat ,to jest problem,gdyż wiąże się w jakimś stopniu z kwestią optymalności naszej bazy danych.

To wszystko zależy. Nie można uogólniać. Może się okazać, że akurat jedno zapytanie będzie o niebo szybsze od trzech robiących to samo. Ale może się okazać zupełnie odwrotnie. Wszystko zależy od zapytań i struktury bazy.

Myślę,że to jest odpowiedź na temat założony przez wszerada

Pytanie było:
sens używania relacji

Moja odpowiedź, którą zacytowałeś, ma się nijak do tego pytania. Moja odpowiedź była kierowana na Twój post. Moją odpowiedzią było to, że zapytanie pomimo że jest złożone, nie oznacza, że będzie wolniejsze od 3 prostrzych. Może się okazać wręcz odwrotnie i często tak nawet jest.

Co do sensu relacji:
sens jest zawsze, nie wyobrażam sobie normalnej bazy bez relacji. Trzeba tylko umieć tworzyć relację z głową. Tak jak przykładowo przykład z imionami był tworzony bez głowy

A, i wykorzystanie relacji wcale nie oznacza, że zapytanie jest "złożone"