Witam.

Mam problem z talibcami do polaczen.
Zastanawiam sie czy lepiej robic wiele podobnych do siebie tablic, czy jedna ogolna.

Koncepcja wielu tabel:
Polaczenie artykulu z zdjeciami
content_id - klucz glowny - z relacja
imagest_id - klucz glowny - z relacja

Polaczenie artykulu z kategoria
content_id - klucz glowny - z relacja
categories_id - klucz glowny - z relacja
I tak dla kazdego polaczenia

Koncepcja jednej tabeli:
first_id
first_extension_id
second_id
second_extension_id

Plusy rozwiazania z jedna tabela sa takie, ze jest jedna tabela do wszystkich polaczen. natomiast wielu tabel ze sa scisle relacje pomiedzy nimi, zachowuje sie integralnosc bazy danych na poziomie samego mysql.
Nie rozpisywalem sie z dodatkowymi rzeczami (jakimis parametrami itp, takie tez istnieja) poniewaz to jest najmniej istotne.

Co sadzicie o tych dwoch rozwiazaniach ? A moze macie lepszy pomysl ?

Zgodnie z normami byłbym za wieloma tabelami - jedna tabela zbiorcza w zasadzie nic nie daje - ciężko będzie użyć jej tak naprawdę w sposób taki aby można było wykorzystać jeden rekord takiej tabeli do wielu powiązań. Jak by się zagłębić w to okazałoby się to bardziej skomplikowane, mniej intuicyjne i nawet może mniej wydajne (przy tworzeniu i aktualizacji takich rekordów - także przy usuwaniu jakiejś pojedyńczej relacji) od wersji z wieloma tabelami.

Wiele tabel daje porządek.

Przy usuwanie jak masz na wielu i usuwasz np. zdjęcie od artykułu to po prostu kasujesz wiersz... w jednej tabeli musiałbyś sprawdzić czy czasem ten wiersz nie ma też istniejącej innej relacji - zaplanowanie relacji i kaskady tutaj nic nie da jeśli będą dwa kluczę obce do rzeczy zupełnie nie związanych ze sobą - można przez to coś pogubić itd...

Drugie przeciw jest takie, że mając jedną tabelę będzie ona używana zawsze przy wszystkich joinach itd... przez co rozłożenie tego na więcej tabel może poprawić wydajność (mniej rekordów na jedną tabelę, mniejsza liczba indeksów - ogólnie szybciej)

Podsumowując - nie kombinowałbym. W przypadku relacji ManyToMany przyjeło się tworzyć tabele pośredniczące z dwoma indeksami określającymi powiązane rekordy. W specyficznych przypadkach gdy relacja jest warunkowa bądź wymaga dodatkowej informacji - do tabeli pośredniczącej dodaje się dodatkowe pola informacyjne. Z koncepcją jak Twoja jeszcze się nie spotkałem

Przykładów używania jednej tabeli do wielu połączeń jest bardzo wiele, a dokładniej wszędzie tam gdzie mam wiele połączeń z rożnymi typami oraz gdzie nie mamy zamkniętej listy elementów z którą będziemy łączyć artykuł. Przykład słynniejszy to WordPress.

Co do prędkości to można tutaj spekulować choć jedno aspekt jest bardzo ważny w przypadku dużego ruchu (sporo selektów) w serwisie / aplikacji edytowanie tej tabeli będzie blokowało selekty które pobieraj dane z tej tabeli co może skutkować czekanie selektów na odblokowanie tabeli, sytuacje nie będzie poprawiła jeszcze wielkości indeksów co dodatkowo spowoduje wydłużenie czasu edytowania. Z drugiej strony jest wiele technik na obejście tych problemów. W przypadku edycji artykułu i rozwiązania z wieloma tabelami problemy będą podobne tyle tylko że będą wisiała w locku 3 tabele (lub więcej) pewnie krótszą ilość czasu z powodu mniejszych indeksów ale będą.

Integralność danych można zachować na poziomie MySQL na wiele sposobów chociaż najłatwiejszą jest utworzenie relacji, a w przypadku jednej tabeli trigger, procedury na usuwanie itp.

Resumując uważam że troszkę więcej założeni projektu jest potrzebne aby to rzetelniej ocenić, chociażby:
1) Z iloma zew. elementami różnych typów (kategorie, grafiki,...) będzie wiązany artykuł
2) Czy lista tych elementów z którymi wiążemy ma być zmienna z poziomu aplikacji, czy ewentualnie wszelkie nowe typ dodaje programista (ręczna modyfikacja bazy danych dodanie nowych tabel i relacji)
3) Jakie będą parametry dodatkowe do tych powiązania i czy możemy przewidzieć konstrukcję tabeli która poprawnie przechowa dodatkowe paramenty i pozwoli np zawężać listę ty relacji i będzie wspólna dla wszystkich powiązań.
4) Czy chcemy celowo wprowadzić standard powiązań chociażby z powodu gotowych bibliotek i przygotowanie dokładnego standardu w przyszłym rozwoju aplikacji. Tak aby każdy mógł wykorzystać dokumentacje / biblioteki / gotowe rozwiązania i nie wprowadzał własnych tabel lub dziwnych rozwiązań i bałaganił w projekcie.

A więc w przypadku tylko 2 powiązań rozwiązanie z wieloma tabelami wydaje się OK, jest nawet łatwiejsze do wykonania i utrzymywania. Ale w przypadku wzrostu połączeń artykuł z czymś lub nawet coś <-> coś to rozwiązanie jednej tabel nabiera senesu tym większego im więcej rodzajów połączeń jest realizowany w projekcie.

Zgadzam się z Sephirus, relacja będzie bardziej wydajna, ponadto, łatwiej będzie budować zapytania i kod będzie bardziej czytelny.