Veritabanına kısıtlamalar koymaktan çekinmeyin. Tutarlı bir veritabanına sahip olduğunuzdan emin olursunuz ve bu bir veritabanı kullanmanın iyi nedenlerinden biridir. Özellikle talep eden birkaç uygulamanız varsa (veya yalnızca bir uygulama ancak doğrudan mod ve farklı kaynaklar kullanan bir toplu iş modu ile).
MySQL ile postgreSQL'de olduğu gibi gelişmiş kısıtlamalarınız yoktur, ancak en azından yabancı anahtar kısıtlamaları oldukça ileridir.
Örnek bir örnek alalım, tez şirketindeki kişileri içeren bir kullanıcı tablosu içeren bir şirket tablosu
CREATE TABLE COMPANY (
company_id INT NOT NULL,
company_name VARCHAR(50),
PRIMARY KEY (company_id)
) ENGINE=INNODB;
CREATE TABLE USER (
user_id INT,
user_name VARCHAR(50),
company_id INT,
INDEX company_id_idx (company_id),
FOREIGN KEY (company_id) REFERENCES COMPANY (company_id) ON...
) ENGINE=INNODB;
ON UPDATE deyimine bakalım :
- GÜNCELLEŞTİRME KISITLAMASI : varsayılan : ŞİRKET tablosundaki bir şirket_kimliğini güncellemeye çalışırsanız, bir kullanıcı bu şirkete en az bağlantı verirse motor işlemi reddeder.
- GÜNCELLEME YOK EYLEM : KISITLAMA ile aynı.
- GÜNCELLEME KASADINDA : genellikle en iyisi : bir company_id'i tablo satırında güncellerseniz, motor bu ŞİRKETİ referans alan tüm KULLANICI satırlarında güncelleyecektir (ancak KULLANICI tablosunda tetikleyici etkinleştirilmedi, uyarı). Motor değişiklikleri sizin için takip edecek, iyi.
- ON UPDATE SET NULL : ŞİRKET tablosundaki bir satırda company_id değerini güncellerseniz, motor ilgili USERs company_id değerini NULL olarak ayarlar (USER company_id alanında kullanılabilir olmalıdır). Bir güncellemede bununla ilgili ilginç bir şey göremiyorum, ancak yanlış olabilirim.
Ve şimdi ON DELETE tarafında:
- KISIT SİLME : varsayılan : ŞİRKET tablosundaki bir company_id kimliğini silmeye çalışırsanız, bir kullanıcı bu şirketteki en az bağlantıdan biri hayatınızı kurtarabilirse motor işlemi reddeder.
- EYLEM YOK SİLME : KISITLA aynı
- KASKADI SİLME : tehlikeli : ŞİRKET tablosundaki bir şirket satırını silerseniz, motor ilgili KULLANICILAR'ı da siler. Bu tehlikelidir, ancak ikincil tablolarda otomatik temizleme yapmak için kullanılabilir (bu nedenle istediğiniz bir şey olabilir, ancak kesinlikle bir ŞİRKET <-> KULLANICI örneği için değil)
- ON DELETE SET NULL : avuç : bir ŞİRKET satırını silerseniz ilgili KULLANICILAR otomatik olarak NULL ile ilişki kurar. Hiçbir şirket olmayan kullanıcılar için Null değerinizse, bu iyi bir davranış olabilir, örneğin, kullanıcıları bazı içeriğin yazarları olarak uygulamanızda tutmanız gerekebilir, ancak şirketi kaldırmak sizin için bir sorun değildir.
genellikle benim varsayılan: GÜNCELLEME KASKAD ÜZERİNDEN SINIRLAMAYI SİLME . bazı ON DELETE CASCADEparça tabloları için (günlükler - tüm günlükler değil -, bunun gibi şeyler) ve ON DELETE SET NULLana tablo, yabancı anahtar içeren tablo için KULLANICI tablosu için bir İŞ tablosu gibi bir 'basit özellik' olduğunda.
Düzenle
Bunu yazdığımdan beri uzun zaman oldu. Şimdi önemli bir uyarı eklemem gerektiğini düşünüyorum. MySQL, kaskadlarla ilgili büyük bir belgelenmiş sınırlamaya sahiptir. Kaskadlar tetikleyici değildir . Bu motorda tetikleyicileri kullanmak için yeterince güvendiğiniz takdirde kaskad kısıtlamalarından kaçınmalısınız.
MySQL tetikleyicileri yalnızca SQL ifadeleriyle tablolarda yapılan değişiklikler için etkinleştirilir. Görünümlerdeki değişiklikler veya SQL deyimlerini MySQL Sunucusuna iletmeyen API'ler tarafından yapılan tablolardaki değişiklikler tarafından etkinleştirilmezler.
==> Son düzenlemenin aşağısına bakın, işler bu alanda ilerliyor
Tetikleyiciler yabancı anahtar eylemleri tarafından etkinleştirilmez.
Ve bunun bir gün düzeltileceğini sanmıyorum. Yabancı anahtar kısıtlamaları InnoDb depolama alanı, Tetikleyiciler ise MySQL SQL motoru tarafından yönetilir. Her ikisi de ayrılır. Innodb, kısıtlama yönetimine sahip tek depolama alanıdır, belki bir gün doğrudan depolama motoruna tetikleyiciler eklerler, belki de değil.
Ancak, zayıf tetikleme uygulaması ile çok faydalı yabancı anahtar kısıtlamaları desteği arasında hangi öğeyi seçmeniz gerektiğine dair kendi fikrim var. Ve veritabanı tutarlılığına alıştıktan sonra PostgreSQL'i seveceksiniz.
12/2017-MySQL ile ilgili bu düzenlemeyi güncelleme:
@IstiaqueAhmed tarafından belirtildiği gibi yorumlarda durum bu konuda değişti. Bu yüzden bağlantıyı takip edin ve gerçek güncel durumu kontrol edin (gelecekte tekrar değişebilir).
ON DELETE CASCADE : dangerous- bir tutam tuz ile alın.