Penso che si sono confusi su due questioni diverse, quando usare InnoDB invece di MyISAM, e quando usare estera chiave (FK).
Per quanto riguarda il primo numero, ci sono state molte risposte che fanno un ottimo lavoro per spiegare le differenze tra MyISAM e InnoDB. Mi limiterò a ripetere che, nella citazione di tvanfosson da un articolo, MyISAM è più adatto per sistemi con letture per lo più. Questo perché utilizza il blocco a livello di tabella anziché a livello di riga come InnoDB, quindi MyISAM non è in grado di gestire una concorrenza elevata, inoltre mancano funzionalità che aiutano l'integrità dei dati come transazioni e chiavi esterne (di nuovo, già menzionate da altri).
Non è necessario utilizzare i vincoli FK nel modello dati. Se sai quali sono le relazioni tra i tuoi tavoli e la tua applicazione è priva di bug, ti ritroverai senza FK. Tuttavia, l'utilizzo di FK garantisce un'assicurazione aggiuntiva a livello di database, in quanto MySQL non consente all'applicazione di inserire dati non validi in base ai vincoli creati.
Nel caso in cui non sono chiare su perché utilizzare chiavi primarie (PK), facendo una colonna come id_order per esempio PK della tabella orders significa che MySQL non INSERT lascerà lo stesso valore di id_order più di una volta perché ogni riga in una colonna PK deve essere unica.
Un FK verrebbe utilizzato su una tabella che ha una dipendenza su un'altra tabella, ad esempio, order_items avrebbe una dipendenza su orders (sotto). id_order_items è la PK di order_items e si potrebbe fare id_order_items l'FK del tavolo orders di stabilire una relazione uno-a-molti tra orders e order_items. Allo stesso modo, id_item potrebbe essere un FK nella tabella order_items e un PK nella tabella items per stabilire una relazione uno-a-molti tra order_items e items.
** Allora, che il vincolo di FK fa è impedire di aggiungere un id_item value to the order_items table that isn't in the articoli table, or from adding a id_order_items to ordini that isn't in the order_items `tabella.
Tutto ciò che un FK fa è assicurare l'integrità dei dati e aiuta anche a comunicare le relazioni tra le tabelle con altri sviluppatori che non hanno scritto il sistema (e te stesso mesi dopo quando dimentichi!), Ma principalmente per l'integrità dei dati. **
credito extra: così perché uso le transazioni? Beh, hai già menzionato una citazione che dice che sono utili per il sistema bancario, ma sono utili in un numero di situazioni superiore a quello.
Fondamentalmente, in un database relazionale, in particolare se si tratta di normalized, un'operazione di routine come l'aggiunta di un ordine, l'aggiornamento di un ordine o l'eliminazione di un ordine spesso sfiora più di una tabella e/o coinvolge più di un'istruzione SQL. Potresti anche finire a toccare la stessa tabella più volte (come nell'esempio qui sotto). Btw Data Manipulation Language (DML) (INSERT/UPDATE/DELETE) coinvolgono solo una tabella alla volta.
Un esempio di aggiunta di un ordine:
vi consiglio una tabella orders e una tabella order_items. Ciò che lo rende così può si può avere un PK sul id_order nella tabella orders, il che significa id_order non può essere ripetuta in orders. Senza il 1-a-molti orders - rapporto order_items, che avrebbe dovuto avere più righe nella tabella orders per ogni ordine che ha avuto più elementi ad esso associati (avete bisogno di un tavolo items troppo per questo sistema di e-commerce btw). Questo esempio aggiungerà un ordine e toccherà 2 tabelle in questo modo con 4 diverse dichiarazioni INSERT.
(vincoli chiave per scopo illustrativo)
-- insert #1
INSERT INTO orders (id_order, id_order_items, id_customer)
VALUES (100, 150, 1)
-- insert #2
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 1)
-- insert #3
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 2)
-- insert #4
INSERT INTO order_items (id_order_items, id_item)
VALUES (4, 3)
Che importa se l'inserto # 1 e inserto # 2 query vengono completate correttamente, ma il inserto # 3 dichiarazione non ha ? Si finirebbe con un ordine in cui mancava un articolo, e si tratterebbe di dati inutili. Se in quel caso, si vuole far ritirare tutte le query in modo che il database è nello stesso stato in cui era prima di aggiungere l'ordine e poi ricominciare da capo, bene che è esattamente ciò che le transazioni sono per. ** Raggruppa le query che vuoi siano eseguite tutte o in caso di eccezione, quindi nessuna, in una transazione.
Così come vincoli PK/FK, le transazioni contribuire a garantire l'integrità dei dati **
vostro esempio sta facendo chiavi esterne, non InnoDB. Avresti dovuto chiedere quali sono le chiavi esterne. –
Che "offensivo"? Questo articolo riguarda come recuperare da un DATABASE DROP involontario. –
Jim Ferrans: Mi riferivo alla frase: "se non sei un programmatore con grande esperienza, farai del male". –