Neden katılımcılar için birincil anahtar / yabancı anahtar eşleşmeleri kullanılmıyor?

Öğrenebileceğim kadarıyla, birçok DBMS (örneğin, mysql, postgres, mssql) veri değişikliklerini sınırlamak için fk ve pk kombinasyonlarını kullanıyor, ancak birleştirme sütunlarını otomatik olarak seçmek için nadiren kullanılıyor. Neden? Eğer 2 tablo arasında bir pk / fk ile bir ilişki tanımlamışsanız, neden veritabanı bu tablolara katılırsam pk / fk sütunlarına katılmak istediğimi bulamıyor?

EDIT: biraz açıklığa kavuşturmak için:

Bir tablo1 ve bir tablo2 olduğunu varsayalım. tablo1'de, sütun 2'de bulunan ve sütun 2'deki birincil anahtara b. Şimdi bu tablolara katılırsam, şöyle bir şey yapmam gerekecek:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

Ancak, zaten tablo1.a'nın table2.b dosyasına referans veren anahtarları kullanmamı tanımladım, bu yüzden bana bir DBMS sisteminin otomatik olarak table1.a ve table2.b'yi birleştirme sütunları olarak kullanması zor olmamalı gibi görünüyor. öyle ki basitçe kullanabilirsiniz:

SELECT * FROM table1
AUTO JOIN table2

Ancak, pek çok DBMS böyle bir şey uygulamak görünmüyor.

Çoğu durumda, iki masaya katılmanın birden fazla yolu vardır; Pek çok örnek için diğer cevaplara bakın. Tabii ki, bu durumlarda 'otomatik birleştirmeyi' kullanmanın bir hata olacağını söyleyebiliriz. Daha sonra, kullanılabileceği basit vakalardan sadece bir tanesi geride kalacaktı.

Ancak, ciddi bir sakınca var! Bugün doğru olan sorgular, aynı tabloya ikinci bir FK ekleyerek yarın hata yapabilir!

Tekrar söyleyeyim: sütun ekleyerek, bu sütunları kullanmayan sorgular 'doğru' ifadesinden 'hataya' dönüşebilir!

Bu böyle bir bakım kabusu, herhangi bir aklı başında tarzı rehber bu özelliği kullanmak yasaklamak olacaktır. Çoğu zaten select *aynı nedenle yasaklıyor !

Tüm bunlar, performansın arttırılması durumunda kabul edilebilir olacaktır. Ancak, durum böyle değil.

Özetle, bu özellik yalnızca sınırlı sayıda basit durumda kullanılabilir, performansı artırmaz ve çoğu stil rehberi yine de kullanımını yasaklar.

Bu nedenle çoğu veritabanı üreticisinin zamanlarını daha önemli şeyler için harcamayı seçmesi şaşırtıcı değildir.

Yabancı anahtar, verileri sınırlamak içindir . yani referans bütünlüğünü güçlendirmek. Bu kadar. Başka hiçbir şey.

1. Aynı tabloya birden fazla yabancı anahtarınız olabilir. Bir gönderinin başlangıç ​​noktası ve bitiş noktası olduğu noktaları göz önünde bulundurun.

   table: USA_States
   StateID
   StateName
   
   table: Shipment
   ShipmentID
   PickupStateID Foreign key
   DeliveryStateID Foreign key
   

   Alma durumuna bağlı olarak katılmak isteyebilirsiniz. Belki teslimat durumuna katılmak istersin. Belki her ikisi için de 2 birleştirme yapmak istersin! Sql motorunun ne istediğini bilmenin bir yolu yoktur.

2. Genellikle birleştirme skaler değerlerini geçeceksiniz. Skalarlar genellikle ara hesaplamaların sonucudur, ancak bazen tam olarak 1 kayıt olan özel bir amaç tablosuna sahip olacaksınız. Motor birleşim için bir foriegn anahtar tespit etmeye çalıştıysa .... bu mantıklı olmaz çünkü çapraz birleşme asla bir sütuna uymaz.

3. Bazı özel durumlarda, hiçbirinin benzersiz olmadığı sütunlara katılırsınız. Bu nedenle, bu sütunlarda bir PK / FK varlığı mümkün değildir.

4. Eğer sorular var ne zaman çünkü noktaları 2 ve 3 yukarıdaki ilgili değildir düşünebilir IS tablolar arasında tek PK / FK ilişkisi. Ancak, tablolar arasında tek bir PK / FK bulunması, PK / FK'ye ek olarak başka alanlara da sahip olamayacağınız anlamına gelmez. Sql motoru hangi alanlarda katılmak istediğinizi bilemez.

5. Diyelim ki "USA_States" adlı bir tablonuz ve eyaletlere FK içeren diğer 5 tablonuz var. "Beş" tablonun da birbirlerine birkaç yabancı anahtarı vardır. Sql motoru otomatik olarak "USA_States" olan "beş" masayı birleştirmeli mi? Yoksa "beş" i birleştirmeli mi? Her ikisi de? İlişkileri, sql motorunun bir araya gelmeye çalışırken sonsuz bir döngüye girmesi için ayarlayabilirsiniz. Bu durumda sql motorunda ne istediğinizi tahmin etmek imkansızdır.

Özetle: PK / FK'nin masa birleşimi ile ilgisi yok. Onlar alakasız şeylerdir. Bu sadece PK / FK sütunlarına katıldığınız bir doğa kazası.

Sql motorunun tam, sol, sağ veya iç birleşim olup olmadığını tahmin etmesini ister misiniz? Sanmıyorum Bununla birlikte, tartışmaya katılacak sütunları tahmin etmekten daha az bir günah olacaktır.

“birleştirilebilirlik” kavramı. İlişkiler r1ve r2birleştirilebilirler ve eğer sadece aynı isimdeki nitelikler aynı türde ise ... bu kavram sadece katılmak için değil, aynı zamanda [birlik gibi] diğer çeşitli işlemlere de uygulanır.

SQL ve İlişkisel Teori: Doğru SQL Kodunu CJ Tarihine Göre Yazmak

Standart SQL zaten NATURAL JOINmySQL içinde bilinen ve uygulanmış olan bir özelliğe sahiptir.

Her ne kadar öneriniz çok değerli olmasa da, makul görünüyor. ( Desteği olmayanNATURAL JOIN ) SQL Server ile Management Studio'da SQL İstemi kullanıyorum: bir INNER JOINInteliSense yazarken ONhem ortak özellik adlarına hem de yabancı anahtarlara dayanan cümle önerileri önerir ve çok yararlı buluyorum. Bununla birlikte, bunun için yeni (standart) bir SQL birleştirme türü görmeyi çok istemiyorum.

SQL ilk geldi!

Yabancı Anahtarlar ve Yabancı Anahtar kısıtlamaları daha sonra geldi ve esas olarak "işlem" tarzı uygulamalar için bir optimizasyondur.

İlişkisel veritabanları başlangıçta ilişkisel cebir kullanılarak matematiksel olarak kanıtlanabilecek bir şekilde veri kümelerine karmaşık sorgular uygulama yöntemi olarak düşünülmüştür . IE belirli bir veri kümesi ve verilen bir sorgu için her zaman tek bir doğru cevap vardır.

İlişkisel veritabanları o zamandan bu yana uzun bir yol kat etti ve işlemsel sistemler için kalıcılık katmanı olarak birincil kullanım, CODD et. hepsi öngörülen.

Bununla birlikte, ANSI standartları, tüm çelişkili hedefleri ve satıcı politikaları için, her zaman SQL'in "matematiksel olarak kanıtlanabilir" özelliklerini korumak için çaba sarf etmiştir.

Veritabanının "gizli" yabancı anahtar verilerinden birleştirme özelliklerini çıkarmasına izin verirseniz, bu özelliği kaybedersiniz (tanımlanmış birden fazla yabancı anahtar kümesi varsa belirsizliği göz önünde bulundurun).

Ayrıca, SQL'i okuyan bir programcı, iki tablo için şu anda hangi yabancı anahtarların tanımlandığını bilmeyecek ve sorgunun ne yaptığını bulmak için veritabanı şemasını incelemesi gerekecektir.

Bir Yabancı Anahtar ilişkisi tanımlamış olsanız da, bu, tüm sorgularda tablolara katılmak istediğin anlamına gelmez. Tabloları birleştirmek için en muhtemel yöntemdir, ancak doğru olmadığı durumlar da vardır.

• Bir amaç için iki tablonun bir Kartezyen ürününü veya bir bölümünü kullanmak isteyebilirsiniz.
• Başka bir amaç için katılabileceğiniz başka alanlar olabilir.
• Üç veya daha fazla tabloya katılıyorsanız, tablolardan biri tablolardan iki veya daha fazlası ile ilişkili olabilir. Bu durumda, genellikle olası FK ilişkilerinden sadece biri sorguda uygun olabilir.

Sahte bir varsayımda çalışıyor olabilirsiniz. 'Öğrenebildiğiniz kadarıyla' diyorsunuz, ancak herhangi bir ampirik veya kanıt kanıtı vermeyin. Eğer bir sorgu için pk veya fk en iyi endeks ise, kullanılacaktır. Bunu neden gördüğünü bilmiyorum, ama benim fikrim kötü oluşturulmuş sorgular.

Sorunun tamamen yeniden yazıldığını şimdi düzeltin: Açıkladığınız durum yalnızca çok küçük bir sorgu kümesi için geçerli olacaktır. Ya 12 masa katıldı ise? Peki ya FK'ler olmasaydı .... Varsayılan bir birleşme olsa bile, her zaman sadece okunabilirlik için birleşim belirtirdim. (Verilere bakmak ve sonra neyin birleştirildiğini anlamaya çalışmak istemiyorum)

Bazı Sorgu araçları aslında sizin için otomatik bir birleştirme işlemi yapar, ardından birleştirme işlemini kaldırmanıza veya düzenlemenize izin verir. Bence MS Access'in Sorgu Oluşturucusu bunu yapıyor.

Son olarak, ANSII standardı birleşimin belirtilmesi gerektiğini belirtir. Buna izin vermemek için yeterli sebep bu.

Yabancı Anahtarların eklenmesi / kaldırılması, uygulamanın kaynak kodundaki sorgular dahil olmak üzere önceden yazılmış sorguların anlamını değiştireceği gerçeği dahil olmak üzere , veritabanının güvenli bir şekilde yapamamasının birçok nedeni vardır . Çoğu veritabanında, yapmak isteyebileceğiniz tüm olası birleşmeleri kapsayan iyi bir Yabancı Anahtar kümesi de yoktur. Ayrıca daha iyisi veya değeri için, Yabancı Anahtarlar genellikle sistemleri hızlandırmak için kaldırılır ve dosyadan "yanlış" sırayla yüklenen tablolarda kullanılamaz.

Bununla birlikte, bir sorgu tasarım aracının veya metin düzenleyicisinin, Yabancı Anahtarların yardımıyla bir birleşmeyi sütun adında istihbarat verdikleri gibi otomatik olarak tamamlayamaması için hiçbir neden yoktur . Araç yanlış yaptıysa sorguyu düzenleyebilir ve tamamen tanımlanmış bir sorguyu kaydedebilirsiniz. Bu tür bir araç aynı zamanda Yabancı Anahtarlar sütunlarının “ebeveyn” tablo adıyla ve aynı addaki sütunların hem ana / alt tablo vb.

(Eşim Management Studio ile Sql Server arasındaki farkı hala anlayamıyor ve yönetim stüdyosunu başlattığında sql sunucusunu başlatma hakkında konuşuyor!)

Doğal birleştirme "otomatik olarak" ortak sütunların eşitliğine katılır, ancak bunu yalnızca tablo anlamlarına ve istediğiniz sonucuna göre istediğiniz şekilde yazmalısınız. İki tablonun "nasıl" birleştirileceğini veya herhangi bir şekilde "herhangi bir tablonun" bir sorguda görünmesini bilen "otomatik olarak" yoktur. Sorgu için kısıtlamaları bilmemize gerek yok. Bunların varlığı sadece girdilerin sınırlı olabileceği ve sonuç olarak çıktıların da olabileceği anlamına gelir. Bildirilen kısıtlamalara "otomatik olarak" katılan bir tür join_on_fk_to_pk işleci tanımlayabilirsiniz; İsterseniz sadece kısıtlamalar değiştirmek ancak tablo değil anlamları o zaman bu sorguyu değiştirmek zorunda olsaydın ama sorgunun anlamı aynı kalmak değil yeni ilan constaints kullanın.Zaten herhangi kısıt değişikliklere rağmen anlam aynı bırakır .

Kısıtlamalar (PK, FK, UNIQUE & CHECK dahil) hangi tabloların ne anlama geldiğini etkilemez. Tabii ki, eğer tablo anlamları değişirse, o zaman çelişkiler değişebilir. Ancak kısıtlamalar değişirse, sorguların değişmesi gerektiği anlamına gelmez.

Bir sorgulamak için kısıtlamaları bilmek gerekmez. Kısıtlamaları bilmek, kısıtlama tutmadan aynı cevabı vermeyecek başka ifadeler kullanabileceğimiz anlamına gelir. Örneğin UNIQUE aracılığıyla bir masanın bir satırının olmasını beklediğimiz için skaler olarak kullanabiliriz. Bu sorgular, kısıtlamanın kabul edildiği, ancak bildirilmediği takdirde bozulabilir. Ancak, sorgunun varsaymadığı bir kısıtlama belirtilmesi onu kıramaz.

İnsan tarafından okunabilir bir açıklamadan SQL sorgusu oluşturmak için herhangi bir temel kural var mı?

Sebebi, DİL olduğu ve altında yatan prensiplerin olmasıdır. Dil, genel amaçlı bir dilde görmeyi beklediğiniz birçok özelliğe sahip değildir. Bu sadece dile eklenmemiş ve muhtemelen olmayacak güzel bir özellik olarak gerçekleşiyor. Ölü bir dil değil, umut var, ama iyimser olmazdım.

Diğerlerinin de belirttiği gibi, bazı uygulamalarda join (sütun) ortak bir sütun adına göre iki tabloyu birleştiren bir uzantı kullanır, ki bunlar biraz benzerdir. Ancak yaygın olarak yayılmıyor. Bu uzantının, SELECT * FROM employee NATURAL JOIN department;hangi sütunların kullanılacağını belirtmenin bir yolunu içermeyen sözdiziminden farklı olduğunu unutmayın . İki tablo arasında güvenilmez hale getiren bir ilişkiye de güvenmeyin (doğal birleştirme sözdizimi uzantısından daha fazlası).

PKFK'nın "iki tablo arasında tanımlanan yabancı anahtar ilişkisi" anlamına gelen bir anahtar kelime olduğu "PKFK'da iç birleştirme tablosu" için temel bir engel yoktur, aynı tabloda birden fazla fk ile ilgili sorunlar olabilir, ancak bu yalnızca bir hataya neden olabilir. Mesele şu ki, dili tasarlayan insanlar, a) iyi bir fikir ve b) üzerinde çalışmak için diğer bazı dil değişikliklerinden daha iyi olduğunu düşünüyorlar ...

ON fıkrasının ihmal edilmesinin referans bütünlüğüne göre alanları takip ettiği varsayılırsa, Kartezyen ürünü nasıl yaparsınız?

Düzenleme: AUTO kullanma Bunun avantajları biraz daha az yazı yazmaktır ve bunların nasıl birleştirildiğini bilmek veya karmaşık bir birleşimi hatırlamak zorunda değilsiniz. İlişki değişirse, otomatik olarak ele alınır, ancak erken gelişim dışında bu nadiren olur.

Şimdi yapmanız gereken, tüm AUTO'larınızın bir ilişkisel değişim sırasında select ifadenizin amacına uygun olması için bekletip beklemeyeceğine karar vermektir.

Neden veritabanı bu tablolara katılırsam pk / fk sütunlarına katılmak istediğimi bulamıyor?

Sebep kısımları:

1 - Teoride iki tablodaki isteğe bağlı sütunlarda tabloları birleştirebilirsiniz. Bu yaygın bir uygulama olmasa da geçerlidir. SQL’in bir programlama dili gibi olduğunu unutmayın, elbette, sütunların içinde hangi bilgilerin olduğunu, SQL’in ne anlama geldiğini anlamamaktadır.

2 - Farklı tipte eklemler vardır (sol, sağ, iç) - İç Katmalar bunlardan sadece 1 tanesidir.

3 - SQL standardı, daha yüksek seviyedeki lehçelerin onu kullanarak istihbarat oluşturmasını sağlayan düşük seviyeli bir dil olma ilkesiyle yönlendirilebilir. Eğer bir üçüncü nesil dili vs 3. nesil bir dil düşünüyorsanız, bu karşılaştırma biraz daha netleşir. Aslında, kullandığım bir araç, IEF, şöyle bir şey yazmanıza izin verdi:

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

Özet olarak öneriniz ilginçtir ve standardın bir parçası olarak veya saklı bir prosedür olarak uygulanabilir (bir İç Birliğe varsayılan olacaktır).

Tiddo, tamamen haklı olduğuna inanıyorum, bu konudaki SQL oldukça aptal ve on yıl önce SQL öğrenirken yabancı anahtarlar için de aynı şeyi düşündüğümü hatırlıyorum.

Tamam, buna göre, sonunda sınavı geçmek zorunda kaldım; ve onu geçmek için bırakmam gerekiyordu . SQL, herkesin kabul edebileceğinden daha fazla bir tren kazasıdır, standardizasyon yolu tam bir felakettir ve bazı uygulamalar tehditkar bir şekilde tamamlanmıştır . Yine de genel olarak oldukça kullanışlı. (Ben K / V luddite değilim)

Yabancı anahtarlar, o zaman ... hiç de kullanışlı değil. İlişkisel modelde önemli bir kavramdırlar , tamam, fakat aynı isimdeki SQL özelliği de iyi karşılaştırılmaz.

Dürüst olmak gerekirse: Performans problemleri olan büyük bir sisteme ulaşana kadar hiç denilen bu SQL özelliğini kullanmayınForeign Key . Açıkça motoru anlatan yabancı bir anahtardır ve hangi değildir tarla olan sadece endeksleme için kullanılır ve bu db kullanıcıya görünmez.

Yanıltıcı mı?
Evet.

30 yıl boyunca insanların yanlış yönlendirilmesinden sonra bunu daha güçlü hale getirecekler mi?
Bir şans değil.

Gerekli olana kadar tamamen Yabancı Anahtarları görmezden gelmek ... benim için SQL düzeltildi ?
Evet!

Ve neden tüm bu halt ilk etapta oldu?
Eh, özellik yabancı anahtarları diyoruz to SQL, sonradan eklenmiş; SQL, zaman içinde aşağıdan yukarıya doğru gelişen bir standarttır. Satıcılar gülünç özellikler uygularken, standart kurumlar yüz yüze geldi.

Dediği gibi yabancı anahtarlar, sadece indeksleme amaçlı olduğu ve JOIN yapısının bulunmadığı yerlerde. (ile yapılır nerede katılır SELECTsorgular, JOINsorguları oldukça yakın ve sadece takma bir anlamda değildir SELECTişlevsellik) Muhtemelen olsa o indeksleme bayrağını mi sesleniyor FOREIGN KEY, bir oldu akıllı adlandırma-hack ilişkisel db teorisi kavramları üzerinde.