Czy naprawdę potrzebne są tabele relacji?

Tabele relacji zawierają głównie dwie kolumny: IDTABLE1 i IDTABLE2.Czy naprawdę potrzebne są tabele relacji?

Jedyną rzeczą, która wydaje się zmieniać między tabelami relacji, są nazwy tych dwóch kolumn i nazwa tabeli.

Byłoby lepiej, gdybyśmy utworzyć jedną tabelę Relationships iw tym stole kładziemy 3 kolumny:
TABLE_NAME, IDTABLE1, IDTABLE2, a następnie korzystać z tej tabeli dla wszystkich relacjach?

Czy jest to dobre/dopuszczalne rozwiązanie w tworzeniu aplikacji internetowych? Co byłoby wadą tego?

Uwaga:
Dziękuję wszystkim za opinię. Doceniam to.
Ale myślę, że bierzesz to trochę za daleko ... Każde rozwiązanie działa do pewnego momentu.
Jako prosty plik tekstowy do przechowywania danych jest dobry do pewnego momentu, niż Excel jest lepszy, niż MS Access, niż SQL Server, niż ...
Szczerze mówiąc, nie widziałem żadnego argumentu, który stwierdza, dlaczego to rozwiązanie jest źle dla małych projektów (z DB wielkości kilku GB).

Źródło

2011-02-08 This is it

Dlaczego nie pójść o krok dalej i zrobić tylko jeden wielki stół z 4 kolumnami: TABLE_NAME, ID, COLUMN_NAME, VALUE? –

@Martinho Fernandes - Z pewnością potrzebujesz tylko trzech kolumn, identyfikator i column_name mogą być łączone razem za pomocą podkreślenia. – Paddy

@Paddy: Nie, to byłaby mikrooptymalizacja. Zapobiegnie to używaniu podkreśleń w identyfikatorach. –

Zły pomysł.

W jaki sposób wymusić zagranicznych kluczy, jeśli IDTABLE1 może zawierać id s z dowolnego stołu w ogóle?

Aby uzyskać akceptowalną wydajność w połączeniach bez obciążenia niepotrzebnego IO, aby wprowadzić całkowicie niepowiązane wiersze, potrzebny byłby złożony indeks z wiodącą kolumną TABLE_NAME, która w zasadzie kończy się na podzieleniu stołu na sekcje.

Oczywiście nawet przy tej pseudo partycjonowaniu nadal marnujesz dużo miejsca w tabeli/indeksach, powtarzając tylko nazwę tabeli dla każdego rzędu.

Źródło

2011-02-08 11:49:25

I nie byłoby prawdziwych korzyści dla tak uciążliwego podejścia. +1 – alex

Byłby potworem ze stołu; byłoby to również kłopotliwe. Pod względem wydajności taki stół nie byłby świetnym pomysłem. Nie można również dodać kluczy obcych do takiej tabeli. Naprawdę nie widzę wielu zalet takiego rozwiązania.

Źródło

2011-02-08 11:49:31 alex

Dobra odpowiedź, a także z tego rodzaju projektem tabeli relacji, byłoby naprawdę trudno zapobiec duplikowaniu lub osieroceniu rekordów. – futile

Jeszcze jeden plus: jeśli będziesz potrzebować dodatkowych danych na temat relacji, to jesteś spieprzony. –

Ponadto, aktualizacja takiej tabeli byłaby koszmarem, zwłaszcza przy setkach tysięcy wpisów. – alex

Czy to nie jest duże wydarzenie, że zamierzasz przechowywać tylko 2 pola identyfikatora? Jeśli mam tabelę StudentCourse (lub jeszcze lepiej rejestrowaną), która ma StudentID & CourseID, ale nie będzie EnrollmentDate również w tej tabeli, ponieważ nie wszyscy uczniowie zapisują się na pierwszy dzień zajęć. Wygląda na to, że nie warto dodawać tej kolumny do już rozdętej tabeli, w której większość rekordów będzie miała wartość null.

Zaletą pojedynczej tabeli może być wymaganie, aby aplikacja umożliwiała użytkownikowi/administratorowi tworzenie tych relacji z danymi (podobnie jak pojedyncza tabela odnośników lub list referencyjnych) i unikanie konieczności tworzenia nowego tabela do adresowania tych utworzonych przez użytkownika referencji. Również korzystanie z dynamicznych zapytań może przynieść korzyści. Aplikacja, która wymaga takich dynamicznych wymagań dotyczących struktury danych, może być lepiej dostosowana do schemaless lub bazy danych nosql.

Źródło

2014-05-06 22:21:53 JeffO

Czy naprawdę potrzebne są tabele relacji?

Odpowiedz

Powiązane problemy