İlişkisel bir veritabanındaki bütünlük kısıtlamaları - bunları gözden kaçırmalı mıyız?


10

Çalıştığım şirketin geliştiricileri ile sürekli bir tartışma içerisindeyim çünkü büyük sorguları hızlandırmak ve daha iyi kazanmak için ilişkisel bir veritabanında ilişki uygulamasından (FOREIGN KEY kısıtlama tanımları aracılığıyla) kurtulmanın daha iyi olduğunu söylüyorlar verim.

Söz konusu platform MySQL 5.x'tir ve en azından benim için makul olmayan ilgili tabloların bazı PRIMARY KEY kısıtlamaları eksik olsa bile, FOREIGN KEY ayarlanmamıştır. Belki haklılar ve yanılıyorum, ama bu durum hakkında tartışmak için yeterli argümanım yok.

Üç yıldır tercih edilen yaklaşım budur. Bu şirkette yeniyim (sadece bir ay), ancak ürün “çalıştığı” için, veritabanını geliştirmekte tereddüt var; Yine de, fark ettiğim ilk şey, bir sayfanın yüklenmesi 1 dakika sürüyor (evet, 60 saniye!).

Mevcut durumun ardındaki iddialardan biri, “denormalize” bir veritabanının normalleştirilmiş bir veritabanından daha hızlı olmasıdır, ancak bunun doğru olduğuna inanmıyorum.

İlgili sorguların çoğu, büyük miktarda veriyle çok, çok, çok yavaş çalışmasını sağlayan JOIN işlemlerini içerir (veritabanı milyonlarca satır içerir).

Genel olarak, “CRUD” işlemlerinin işlenmesi uygulama programı kod düzeyinde gerçekleştirilir; örneğin, bazı verileri FROM SİLMEK için, diyelim ki TableA:

  • ilk testi için gerekli anında sıraları arasında bazı ilişkiler varsa TableAve TableB,
  • söz konusu ilişkinin "algılanması" durumunda, uygulama program kodu ilgili satırları SİLMEYE izin vermez, ancak
  • herhangi bir nedenle uygulama program kodu başarısız olursa, ilgili satırlar ve tablolarla ilgili herhangi bir ilişki olursa olsun DELETE işlemi "başarılı" olur.

Soru

Tartışmayı zenginleştirmek için iyi, doğru ve sağlam bir cevap geliştirmeme yardımcı olabilir misiniz?


Not : Belki böyle bir şey daha önce sorulmuştur (ve yanıtlanmıştır), ancak Google aracılığıyla hiçbir şey bulamadım.


Yorumlar uzun tartışmalar için değildir; bu sohbet sohbete taşındı .
Paul White 9

Yanıtlar:


12

Gönderinizde belirtildiği gibi, niyet ilişkisel bir veritabanı (kısaca RDB) oluşturmak ve bu nedenle, bu şekilde çalışması beklenirse, kısa cevap:

  • Hayır, veri bütünlüğü kısıtlamalarını göz ardı etmemelisiniz .

Birincil amaç, ilgili verileri olduğu gibi yönetmek olmalıdır, oldukça değerli bir organizasyonel varlık ve söz konusu hedefe ulaşmak için güvenilir bir yol, sağlam teori üzerinde desteklenen teknik araçlar kullanmaktır.

Bu nedenle, veritabanı uzmanları olarak, iş kurallarını uygulamak için Dr. EF Codd tarafından sağlanan son teknoloji ürünü ve zarif ilişkisel model mekanizmalarından faydalanabilir ve kullanılmazsa ortaya çıkabilecek sorunlardan kaçınabilirsiniz.

Bu bağlamda, (a) genel kısıtlamaları benim üstlenmemi ve (b) veri tabanının durumu ve söz konusu çalışma ortamıyla ilgili çeşitli hususları aşağıdaki gibi paylaşacağım.

FOREIGN KEY kısıtlamaları, veri ilişkileri ve referans bütünlüğü

Bir RDB , iş uzmanlarının vazgeçilmez yardımlarıyla birlikte, en iyi uygulamaları takip eden bir modelci veya tasarımcı tarafından yürütülen derinlemesine kavramsal düzeyde bir analiz gerektiren, ilgili iş bağlamının özelliklerini yüksek doğrulukla yansıtmalıdır . Bu analiz, geçerli iş kurallarının doğru tanımlanmasını ve formülasyonunu sağlamalıdır .

Sonuç olarak, böyle bir modelleyici alaka düzeyi verileri arasında karşılıklı ilişki olduğunu tespit etmişse, veritabanı yönetim sisteminin (DBMS) verilerin kesin özelliklerle tutarlı kalmasını garanti edebilmesi için ilgili mantıksal seviye kısıtlamalarını yapılandırması gerekir. Yukarıda belirtilen analizde belirlenen kurallar her zaman .

Tartışılan veri tabanı ile ilgili olarak, uygulama program kodu (böylece) DBMS tesislerinin dışından onları zorlamak için prosedürel (ve atlaması kolay) bir girişim olduğunu belirttiğinizden, ilgili ilişkilerin tanımlandığı anlaşılabilir. ilişkisel bir yaklaşımdır) her durumda söz konusu karşılıklı ilişkilerin bütünlüğünü doğrulamaya çalışmak için veritabanına “dokunmak” zorundadır.

Ancak, bildiğiniz gibi, referans bütünlüğünü korumak için en uygun teknik bu değildir , çünkü ilişkisel bilim bu amaç için çok güçlü bir araç, yani YABANCI ANAHTAR (FK) kısıtlamaları öngörmüştür. Bu kısıtlamaları oluşturmak çok kolaydır ( gereksiz beyan yaklaşımı yoluyla), gereksiz ve hataya açık geçici prosedürlere başvurmaktan kaçınan tek cümlelerdir . FK kısıtlamalarının yürütme hızının uzman programcılar tarafından oldukça optimize edildiğini (ve büyük platform satıcılarının onlarca yıldır çalıştığını) çok yararlıdır.

Ayrıca, bir RDB, birden fazla uygulama programı (masaüstü, otomatik, web, mobil, bunların kombinasyonları) tarafından erişilebilen bağımsız (kendi kendini koruyan, kendini tanımlayan vb.) Bir yazılım bileşeni olması gerektiğinden, Bu uygulamalardan herhangi birinin koduyla "birleşti".

Aynı şekilde, önemli bir organizasyonel kaynak olan veriler doğal olarak uygulama programlarını, uygulama programcılarını, uygulama geliştirme platformlarını ve programlama paradigmalarını geçme eğilimindedir.

PRIMARY KEY kısıtlamaları ve yinelenen satırların sonuçları

Bir iş ortamında “ kavramsal olarak konuşursak” belirli bir şey önem kazandığı zaman , bir veritabanı modelleyici (1) ilgili özelliklerini (özelliklerini, özelliklerini) belirlemeli, söz konusu şeyi varlık örnekleri prototipi olarak onaylamalıdır - yani, bir varlık türü ve (2) bunu mantıksal bir tasarımda bir veya daha fazla sütunla entegre edilmiş bir tablo aracılığıyla temsil eder .

Sonra, bu tıpkı şeyden her ayırt etmek örneğini gerçek dünyada belirli bir varlık türü, her satır bir içine tabloda benzersiz sıra ayırt edilmelidir. Bir tablonun bildirilmiş KEY'si yoksa, sonunda yinelenenleri koruyacaktır ve tam olarak aynı değerleri tutan iki veya daha fazla satır varsa, hepsi aynı anlamı taşır , hepsi aynı gerçeği temsil eder .

Bu noktada, yinelenen satırlar birden fazla nedenden dolayı atılmalıdır. Teorik bir bakış açısıyla, tasarımcı, her bir satırın SQL veri alt dilinin izin verdiği ölçüde ilişkisel olarak çalışan tablolara (veri işleme işlemlerinde önemli yansımalara sahip olması) her zaman benzersiz olduğundan emin olmalıdır. Birden çok satır aynı gerçeği temsil yanında, eğer bir bilgi bakış açısıyla, onların değil sadece gereksiz ama kayıt zararlı örneklenen olarak feryat:

  • Birisinin belirli bir tabloya iki özdeş satır eklediğini varsayalım.
  • Daha sonra, başkası gelir ve kopyaların yalnızca bir kez güncellenir. Sonuç olarak, diğer olay artık güncel değildir.
  • Art arda, başka bir kişi şu ana kadar değiştirilmemiş olan olayı günceller. Bu şekilde, her iki kopya da zaman içinde farklı noktalarda farklı değişikliklere uğramıştır.
  • Bundan sonra, birisi söz konusu satırların aktardığı bilgileri seçmekle ilgilendiğinde, bunun iki farklı “versiyonunu” bulabilir.

Böylece:

  • Hangi “versiyon” doğru, güvenilir versiyon olarak kabul edilebilir?
  • Hangisi gerçek dünyayı doğru bir şekilde yansıtır?

Bildiğiniz gibi, bu fenomenin yasal sonuçları olabilir, bu kesinlikle çok önemli bir durumdur.

Ayrıca, bu tür çelişkilerin üstesinden gelmek için kullanılması gereken zaman ve çaba (belki de bir çeşit “güncelleme senkronizasyonu” yoluyla) kuruluşunuz için gerçekten değer üreten görevlere daha iyi ayrılmalıdır. Bu nedenle, bir veritabanının tutarlılığını korumak için tasarımla çelişkili satırları korumaktan kaçınılmalıdır .

Bir birincil anahtar (PK) tanımlanması nedeni budur ve ilgili kısıtlama ilan etmelidir hep veritabanı tasarımcısı tarafından gerçekleştirilebilir. Ancak, bir tablonun, her satırı benzersiz bir şekilde tanımlayan değerleri tutan birden fazla sütuna veya sütun kombinasyonuna sahip olabileceği de belirtilmelidir; sonuç olarak, bir PK kısıtlaması oluşturmanın yanı sıra (pragmatik nedenlerden dolayı ideal olarak PRIMARY olarak oluşturulmuştur), tasarımcı da geçerli olduğunda (genellikle bir veya daha fazla UNIQUE plus NOT NULL kısıtlamasıyla tanımlanır) oldukça yaygın).

PK'ların bir başka avantajlı özelliği, tekli veya kompozit FK'lerde yer almak üzere diğer tablolara “taşındıklarında” veriler arasında var olan ilişkilerin kardinalite oranlarının uygulanmasına yardımcı olabilmeleridir . Bütün bunlar, evet, DBMS tarafından sağlanan basit ve verimli bildirim ayarları ile.

(Geçerli) CHECK kısıtlamaları ve tek satırlı doğrulama

Bir satırın geçerli sütun değerleri kümesini (basit olarak görünebilir, ancak aslında ilişkisel bir DBMS'nin temel bir özelliği olan) deklaratif olarak kısıtlayan (geçerli) CHECK kısıtlamalarının alaka düzeyini unutmayalım. iş bağlamının kurallarının her zaman kesin olarak yansıtıldığından emin olabilirsiniz.

Sorunuzu MySQL etiketi ile işaretlediğinizde, maalesef, böyle bir platformun söz konusu kısıtlamanın beyanına izin verdiği, ancak aynı zamanda uygulanmasını görmezden geldiği belirtilmelidir ! anlaşılabilir bir şekilde, 2004'ten bu yana bir hata olarak rapor edildi .

Bu bağlamda, bu faktöre başka yollarla, örneğin ASİT İŞLEMLERİ , TETİKÇELER veya DBMS'nin içindeki diğer yöntemlerle dikkat etmeniz gerekir ( bu konu hakkında bilgi için @ ypercubeᵀᴹ tarafından verilen bu cevaba bakınız ). tutarlı olun.

ASSERTION kısıtlamaları: bildirimsel olarak daha fazla çok satırlı ve çok tablolu iş kuralları oluşturma

Her ne sebeple olursa olsun, MySQL de dahil olmak üzere farklı SQL DBMS'ler tarafından çok kötü bir şekilde desteklenemeyen bir özellik, PK'ların ve FK'ların ötesinde, açık bir şekilde çok satırlı ve çok tablolu kısıtlamaları etkinleştirmektir.

SQL standardı, yıllardır ASSERTION'ları içeriyor. İş ortamınızın hangi kurallarının bu mantıksal düzey doğrulama yaklaşımından faydalanacağını bilmiyorum, ancak bir veritabanı tasarımcısı olarak, bir veya daha fazla BİLDİRİM ile verileri kısıtlamanın oldukça kullanışlı olacağını düşünüyorum. DBMS geliştiricilerinin bakış açısıyla, bu en önemli tür aracın fiziksel soyutlama düzeyinde uygulanması zor olmuştur.

Oracle satıcısının ve / veya geliştiricilerinin 2016'dan beri ASSERTION desteğini değerlendirdiği ve bu DBMS'nin ilişkisel olarak daha uyumlu ve dolayısıyla daha sağlam ve rekabetçi olmasını sağlayacak gibi görünüyor. Sanırım, eğer (i) tüketicileri itmeye devam ederse ve (ii) Oracle uygulamada başarılı olursa, (iii) diğer DBMS satıcıları / toplulukları da onları etkinleştirmek zorunda kalacak ve kullanımları yayılmaya başlayacaktır. Kesinlikle, bu veritabanı yönetimi alanında büyük bir ilerleme olacak ve Dr. Codd tarafından öngörülen en belirgin araçlardan biri olarak, şahsen bunun yakında olacağını göreceğimizi umuyorum.

Veri tutarlılığı ve karar verme süreci

Yukarıda tartışıldığı gibi, bir RDB'nin en önemli yönlerinden biri, tuttuğu verilerin tutarlılığını tek başına garanti etmesidir ve bahsedilen tutarlılık, yalnızca RDB, modelleyici tarafından beyan edilen bütünlük kısıtlamalarına uyduğunda karşılanır.

Bu bağlamda, olması zorunludur baz tablolar üzere korunacak olan bütünlüğü (DDL yapısında belirlenmiş olan) oluşturmak için mümkün türetilmiş olan tabloları (birden fazla tablodan verilerini geri çağırır fazlar bu örneğin bir SELECT deyimi veya bir görünümü) güvenilir , türetilmiş tablolar mutlaka temel tablolar açısından üretilmelidir.

İnsanların bilgiyi örgütsel (ve sıradan) karar verme sürecinde ana araç olarak kullandıkları bilinmektedir. Daha sonra, bir veri tabanı tarafından sunulan bilgiler tutarlı ve doğru değilse, bu bilgilere dayalı kararlar sağlam olmayacaktır (en azından söylemek gerekirse). Bu nedenle bir RDB dikkatli bir şekilde tasarlanmalı ve uygulanmalıdır: kullanıcılarına iyi kararlar vermelerine yardımcı olabilecek güvenilir bir kaynak haline getirilmelidir.

“Denormalization”

Ne yazık ki, “denormalize edilmiş bir veritabanı normalleştirilmiş bir veritabanından daha hızlıdır” yaygın bir yanlış anlamadır, ancak aynı zamanda mantıklı, fiziksel ve pragmatik gerekçelerle reddedilebilecek bir argümandır.

İlk olarak, denormalizasyon mutlaka bir temel tablonun daha önce normalleştirildiğini ima eder (bir veritabanının soyutlama mantıksal düzeyinde yerine getirilen resmi , bilim temelli bir prosedür sayesinde ).

Dolayısıyla, söz konusu tablonun gerçekte doğru bir şekilde normalleştirildiğini varsayarak, onu "denormalize" (bu, kelimenin resmi anlamının aksine, bir reklamdaki diğer tablolara ait olan ve ayrıca bir parçası olan sütunları eklemeyi içerir hoc fashion), örneğin, yalnızca bir veya birkaç belirli SELECT ifadesinin işlenmesini hızlandırmak (fiziksel düzeyde) için yardımcı olabilirken, bu tür bir hareket tarzı aynı zamanda diğer birçok ilişkili verinin yürütülmesini baltalayabilir. manipülasyon işlemleri (örn. birkaç INSERT, UPDATE, DELETE ve SELECT ifadeleri veya bunların kombinasyonları tek veya birden fazla ASİT İŞLEMİ içine alınır).

Buna ek olarak, denormalizasyon (resmi veya gayri resmi olsun) , tüm bunların önlenebileceği karmaşık, maliyetli ve hataya açık prosedürlerle “ele alınabilecek” bir problem olan veritabanının tutarlılığını bozan güncelleme / modifikasyon anormallikleri getirecektir. En başta.

Normalize edilmiş ve "denormalize" tabloları destekleyen fiziksel seviye iskele

Gerçek dünyada kullanılması amaçlanan bir mantıksal (soyut) düzen (SQL-DDL tasarımı), dikkate alınması gereken fiziksel (somut) yansımaları açıkça barındırır.

Bu şekilde, "denormalize" bir tablo mutlaka "daha geniş" (ek sütunlar tutar) olacaktır, bu da satırlarının zorunlu olarak daha ağır olacağı anlamına gelir (daha fazla ve daha büyük fiziksel seviye bileşenleri gerektirir), yani alttaki hesaplama işlemlerinin (ör. , sabit sürücü veya bellekle ilgili olanlar) kolayca daha yavaş dönebilir.

Bunun aksine, elbette “daha ​​dar” (daha az sütuna sahip) olan normalleştirilmiş bir tablo, “daha ​​hızlı davranan” ve daha hızlı davranan “daha ​​hafif” bir unsur olacaktır. , örneğin, veri yazma ve okuma.

Bu şekilde, (a) ilgili tabloları formel ve ihtiyatlı bir şekilde normalleştirmek, bu şekilde tutmak ve daha sonra (b) veri alma ve değiştirme hızını optimize edebilen herhangi bir fiziksel seviye kaynağından yararlanmak, örneğin uygulama uygun yazılım ve donanım sunucusu yapılandırmalarını, ağ bant genişliği yeteneklerini yükseltmeyi vb. sağlayan dikkatli ve verimli bir dizin oluşturma stratejisi.

Söz konusu veritabanının işleyişi

Sorunuzun aşağıdaki paragrafları veri alma işlemlerinin hızı ile ilgilidir:

[A] ürün "çalışıyor", veritabanı geliştirmek için tereddüt var; yine de, ilk fark ettiğim şey bir sayfanın yüklenmesi 1 dakika sürüyor (evet, 60 saniye!).

Belirli bir sayfanın yükü bu kadar fazla alırsa, sistem kullanıcılarının iyi bir hizmet almadığı açıktır; bu nedenle, “çalıştığında” bile, işleyişi hiç de optimal görünmüyor, tüm ortamı (veritabanı ve uygulamalar) daha verimli hale getirme niyetinizin iyi bir şekilde sürdürüldüğünü ve çok yapıcı bir tutum sergilediğini gösteriyor.

O zaman, bilim sizi kesinlikle desteklediğinde ve bu nedenle sağlam bir duruş sürdürmeniz gerektiğinde bile, duruma diplomatik bir şekilde yaklaşmanızı öneririm, çünkü günün sonunda işverenleriniz, meslektaşlarınız ve kendiniz tüm organizasyonu yapmak için çaba gösteriyorlar daha başarılı. Bu nedenle, vurgulamanız gereken bir argüman, diğer şeyleri daha iyi yaparken, genel ve özel veri yönetimi uygulamalarını iyileştirmek, daha örgütsel ve bireysel büyüme üretmeye önemli ölçüde yardımcı olabilir.

İlgili sorguların çoğu, büyük miktarda veriyle çok, çok, çok yavaş çalışmasını sağlayan JOIN işlemlerini içerir (veritabanı milyonlarca satır içerir).

JOIN operatörünün verilerin ilişkisel manipülasyonu ile ilgili önemli ve güçlü bir unsur olduğunu belirtmek gerekir. Daha sonra, daha sağlam platformlar nispeten daha hızlı yürütmelerle hizmet etse de, tanımladığınız durum büyük olasılıkla verimli olmayan bir tasarımın belirtisidir (kavramsal, mantıksal ve fiziksel soyutlama seviyelerinde). İlk görüş tahminlerim:

  • INDEX ayarlarının iyileştirilmesi gerekebilir.
  • PK ve FK sütun tipi ve boyut tanımlarının gözden geçirilmesi gerekir (ve kompozit ANAHTARLAR uygun durumlarda ekteki vekillerden çok daha verimli olma eğiliminde olduğundan, @Rick James'e PK düşüncelerinde tamamen katılıyorum ).
  • Daha fazla (resmi, bilim temelli) normalleştirme , doğru koşullarda (yani, iyi tasarlanmış bir RDB'de gerçekleştirilir), JOIN'lerin çok hızlı yürütülmesi nedeniyle bu sorunları hafifletmeye yardımcı olabilir .

Üstelik evet olarak @TommCatt bahsedildi onun cevabı , bazen (mantıksal) onun (fiziksel) yürütme planı verileri kesinlikle dikkate alınması gereken bir faktördür / yazma, okuma hızlanan bir sorgu tuşelere arasında yeniden yazmak.


1
Mükemmel cevap. Bir uygulamanın performansını düşünürken kendime her zaman hatırlıyorum ki, geliştiricilerden oluşan bir ekip bu problemler üzerinde çok uzun zamandır çalışıyor. İlişkisel veritabanları dünyadaki en muazzam sistemlerin merkezindedir (Facebook ve Twitter, birkaç barik olanı belirtmek için).
Nick Bedford

9

Geliştiricilerinizin temel dayanağı kesinlikle yanlıştır. Yabancı anahtarlar, sisteminizin DML'sinin performansını biraz etkileyecektir. Sorgularda hiç kullanılmazlar, bu nedenle performansları üzerinde hiçbir etkisi yoktur. Yani geliştiricilerin ne hakkında konuştuklarını bilmiyorlar ve tavsiye almayı düşünmeniz gereken son insanlar.

Yabancı anahtarlar verilerinizin bütünlüğünün korunmasında kritik bir rol oynar. Bu, onları kaldırarak (doğru olsa bile) elde edilen küçük performans geliştirmelerinden çok daha önemlidir.

Altında, yapma herhangi bir OLTP veritabanından kaldırma FKs, koşullar.

Ayrıca, denormalizasyon bazen bazı sorguları hızlandıracaktır. Dedikleri gibi değişir. Yine de, bir miktar hız artışı olsa bile, genellikle veri bütünlüğünü korumak için fazladan çabaya değmez.

Basit ayarlama size normalden daha hızlı bir hız artışı sağlayamadığında çok nadirdir. Burada iyi bir DBA (nihayet) ücretini kazanabilir. Sorgularınızı da ayarlayabilirsiniz. Bir keresinde en az 30 dakika içinde bir cevap döndüren bir sorgu aldım ve 8 saniyenin altında çalışmaya başladım. Veritabanında değişiklik yok, sadece sorguyu yeniden yazdınız. Verilmiş, bu benim kişisel en iyi kaydım, bu yüzden kilometreniz değişebilir, ancak denemeniz gereken en son şey denormalize etme olmalıdır.

Ayrıca, daha karmaşık sorguların geliştiriciler tarafından yazılmasını engellemek isteyebilirsiniz. Onlara hangi verileri istediklerini ve hangi formatta istediklerini sorun. Daha sonra bu verileri onlara vermek için görünümler sağlayın. Karmaşık sorgular görüş olacaktır. Geliştiriciler sadece şunu yazmak zorundadır:

select <something> from <SomeView> where <whatever>;

Ben de veritabanı aksi takdirde iyi tasarlanmış varsayıyorum. Veritabanının kötü bir tasarımı, hatta küçük parçaları bile işleri yavaşlatabilir. Sık sık Çok Büyük Tablolar (her biri milyarlarca kayıt) ile birlikte sola ve sağa birleştiren ve saniyenin kesirlerinde beklenen (ve var) cevapları olan sorgularla çalıştım. Bir tablonun boyutu, sorgunun hızını belirleyici değildir.

Birisi "ürün 'çalıştığı için veritabanını geliştirmekte tereddüt olduğu için" dediğinde gerçekten küfrediyorum. Eğer bu "tereddüt" daha çok "saatimde değil, dostum!" hatta özgeçmişinizi güncellemeye başlamak isteyebilirsiniz. Hiç böyle bir ortamdan iyi bir şey gelmez ve başarısızlığı önleyecek bir değişiklik yapmak için saatlerce lobicilik yapmış olsanız bile, gelecekteki her başarısızlık için suçlanacaksınız. Tekrar tekrar "Şimdi değişiklik yapmak için iyi bir zaman değil" ifadesini duyarsınız. Sağ. İyi şanslar.


Dikkat edilmesi gereken bir nokta, bazen döndürülecek veri miktarına bağlı olarak aynı veriler için farklı sorgulara ihtiyaç duymanızdır. Örneğin, tek bir satır (veya yalnızca bir sayı) döndüren bir sorgu, binlerce kayıt döndüren bir sorgudan daha iyi yazılabilir.
Joe W

2

Başlığın değiştirilmesi soruyu değiştirir. FOREIGN KEYsisteğe bağlıdır. Onlar yapar:

  • Bir FK örtük INDEXolarak tablolardan birinde bir oluşturur . Böyle bir indeks manuel olarak eklenebilir. (Yani bunun için FK gerekli değildir .)
  • Bir FK bütünlüğü kontrol eder. FK'nin ana şöhret iddiası budur. Başvurunuz benzer kontroller yapabileceğinden veya bir kontrole gerek olmadığına karar verebileceğinden bir FK gerekli değildir. Yani...
  • Bütünlük kontrolünün performansında bir maliyeti vardır; böylece işlemi yavaşlatır. (Bu genellikle çok önemli değildir.)
  • FK'ler herkesin istediği her şeyi yapmaz; bu forum "FKs neden X yapamıyor" sorularıyla doludur. Özellikle bu CHECKseçenek üzerinde işlem yapılmaz.
  • FK'ler bir CASCADEşeyler yapabilir . (Şahsen, kontrolde kalmayı tercih ediyorum ve FK'nin 'doğru olanı yapacağını' varsaymıyorum.)

FK'ler için sonuç: Bazı insanlar FK'lerde ısrar ediyor; bazı ürünler onlarsız mükemmel bir şekilde yaşar. Sen karar ver.

InnoDB'de kurtulmak PRIMARY KEYbüyük bir hatadır. Öte yandan, bir vekilden kurtulmak AUTO_INCREMENTve bir (veya daha fazla) sütundan oluşan "doğal" bir PK kullanmak genellikle doğru olan şeydir. Basit, yaygın bir durum çoktur: burada tartışıldığı gibi birçok harita tablosu .

Kişisel deneyime dayanarak, tabloların 2 / 3'ünün auto_inc PK yerine 'doğal' kullanmanın daha iyi olduğunu düşünüyorum.


1
Yani ... neredeyse mükemmel bir uygulamaya güveniyorsunuz çünkü bir geliştirici DELETEörneğin bir hata yaparsa ve DB tarafında bir kısıtlama yoksa veri kaybına son vereceksiniz. Bu yaklaşım geçerlidir, ancak sahip olmadıkları yoğun kod ve iyi testler gerektirir :)
ReynierPM

Çok fazla silme uygulamada veya FK ile olabilir. Çok az silme genellikle belirginleşir. OTOH, Çok az silmenin maliyete değdiği durumları gördüm - işlerin nadiren silindiği bir "normalleştirme" düşünün. Ekstra, kullanılmayan sıralar neredeyse zararsızdır.
Rick James

Gördüğüm tek yüksek hızlı yutmaya bir çalışma tablosunda - bir tablo üzerinde hiçbir endeksler için 'iyi' durumda. Çok geçicidir (bu nedenle InnoDB'ye gerek yoktur) ve sadece tamamen okunması gerekir (bu nedenle, indeks gerekmez).
Rick James

1
Tıkırtılarımda ortak bir temaya dikkat edin: Tek bir cevap yok; herkese uyan tek beden yok.
Rick James

Tablolarınız bin satır uzunluğundaysa; performans bir sorun değildir. Tablolarınız milyar satır uzunluğundaysa, normalleştirme, PK'lar, endeksler, FK'ler, UUID'ler vb. İle ilgili tüm "kurallar" ın incelenmesi gerekir. Yoksa db eriyecektir.
Rick James
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.