Zaplanowanie tablic z polaczeniami Opcje

[quality]

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 ?

[Sephirus]

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 (IMG:style_emoticons/default/wink.gif)