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.