Klucze zagraniczne kontra połączenia

Czy lepiej jest używać kluczy obcych w tabelach, czy te same wyniki można osiągnąć przy łączeniach?Klucze zagraniczne kontra połączenia

Źródło

2010-06-01 andrew Sullivan

Jaka jest różnica? Połączenia są definiowane tylko za pomocą kluczy obcych. Oczywiście nie można zdefiniować klucza obcego w bazie danych. Używanie klucza obcego poprawi wydajność (pod warunkiem, że wybór klucza obcego jest właściwy). – Kangkan

'Połączenia są definiowane tylko za pomocą kluczy obcych' Fałsz! 'Używanie klucza obcego poprawi wydajność 'Również fałszywe. W rzeczywistości, jeśli w ogóle, FK może zaszkodzić wydajności, ale tylko rzadko do jakiegokolwiek zauważalnego stopnia, który uzasadnia usunięcie wtedy. – Brandon

@Kangkan tworząc FK nie ma nic wspólnego z wydajnością FK! = Indeksy. Istnieją DBMS automatycznie tworzy indeks w kreacji FK, ale większość nie. Przystawki nie potrzebują FK, proszę zapoznać się z doskonałą odpowiedzią Daniela. Być może OP jest zdezorientowany przez struktury ORM – jean

Foreign keys to tylko ograniczenia, aby wymusić referential integrity. Będziesz nadal potrzebował używać JOINs do budowania zapytań.

klucze obce zagwarantować, że rząd w tabeli order_details z polem order_id odwołującego tabelę orders nigdy nie będzie mieć wartość order_id który nie istnieje w tabeli orders. Klucze obce nie muszą mieć działającej relacyjnej bazy danych (w rzeczywistości silnik MySQL's default storage nie obsługuje FK), ale są one zdecydowanie niezbędne, aby uniknąć zerwanych relacji i osieroconych wierszy (tj. Integralności referencyjnej).

Źródło

2010-06-01 05:26:12

Chcę tylko zwrócić uwagę, że chociaż FK są fajne, to raczej kiepski projekt polega na * poleganiu * na DB dla logiki aplikacji. Twoja aplikacja może się zepsuć bez aktualizacji bazy danych (mnożenie przez instalacje). Niech to też zminimalizuje. –

@sims: Nie uważam "spójności referencyjnej" za logikę aplikacji. Zdolność do egzekwowania więzów integralności na poziomie bazy danych jest wymagana, aby C w [ACID] (http://en.wikipedia.org/wiki/ACID) pozostało. –

@sims: Zgadzam się z Danielem, ale chciałbym przedłużyć jego rozumowanie. IMO RI jest częścią logiki biznesowej (lub "logiki danych"), którą musi być gdzieś egzekwowana (RAZ, nie powtarzaj się). Ponieważ DB jest centralnym/ostatecznym źródłem danych, dane muszą być tam ważne, dlatego jego punkt wywołujący ACID jest poprawny! – lexu

FOREIGN KEY s i JOIN s nie to samo!

FOREIGN KEY wymusza integralność danych, upewniając się, że dane potwierdzają pewnych zasad, gdy jest on dodany do DB.
A JOIN jest używany podczas wyodrębniania/zapytania danych z DB, podając zasady wyboru danych.
JOIN s pracy, jeśli istnieje FK lub nie.
Praca FK, jeśli wyodrębnisz dane z lub bez JOIN s.

WNIOSEK: FK i JOIN nie pozwalają, aby osiągnąć ten sam cel!

Źródło

2010-06-01 05:27:42 lexu

Klucze zagraniczne kontra połączenia

Odpowiedz

Powiązane problemy