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 ?

[radekzm]

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.