Neden SQL sevgisi yok? [kapalı]

Son zamanlarda SQL'in berbat bir dil olduğunu çok duydum ve görünüşe göre güneşin altındaki her çerçeve bir veritabanı soyutlama katmanı ile önceden paketlenmiş olarak geliyor.

Deneyimlerime göre SQL, veri giriş ve çıkışını yönetmenin genellikle çok daha kolay, daha çok yönlü ve daha programcı dostu bir yoludur. Kullandığım her soyutlama katmanı, gerçek bir faydası olmayan, belirgin şekilde sınırlı bir yaklaşım gibi görünüyor.

SQL'i bu kadar korkunç yapan nedir ve veritabanı soyutlama katmanları neden değerlidir?

Bu kısmen özneldir. Yani bu benim fikrim:

SQL, sözde doğal bir dil stiline sahiptir . Mucitler, tıpkı İngilizce gibi bir dil yaratabileceklerine ve veritabanı sorgularının çok basit olacağına inanıyorlardı. Korkunç bir hata. Önemsiz durumlar dışında SQL'i anlamak çok zordur.

SQL bildirimseldir. Veritabanına nasıl bir şeyler yapması gerektiğini söyleyemezsiniz , sadece sonuç olarak ne istediğinizi. Bu mükemmel ve çok güçlü olurdu - eğer performansı önemsemenize gerek kalmasaydı. Böylece, yürütme planını etkilemeye çalışarak SQL'i yeniden ifade ederek - yürütme planlarını okuyarak - SQL yazarsınız ve yürütme planını neden kendiniz yazamadığınızı merak edersiniz .

Bildirim dilinin bir başka sorunu, bazı sorunların zorunlu bir şekilde çözülmesinin daha kolay olmasıdır. Yani ya başka bir dilde yazarsınız (standart SQL ve muhtemelen bir veri erişim katmanına ihtiyacınız olacak) ya da satıcıya özel dil uzantılarını kullanarak, örneğin saklı prosedürler ve benzerlerini yazarak . Bunu yaptığınızda, muhtemelen şimdiye kadar gördüğünüz en kötü dillerden birini kullandığınızı göreceksiniz - çünkü hiçbir zaman zorunlu bir dil olarak kullanılmak üzere tasarlanmadı.

SQL çok eskidir . SQL standartlaştırıldı, ancak çok geç, birçok satıcı zaten dil uzantılarını geliştirdi. Böylece SQL düzinelerce lehçeyle sonuçlandı. Bu nedenle uygulamalar taşınabilir değildir ve bir DB soyutlama katmanına sahip olmanın bir nedeni.

Ancak doğru - uygulanabilir alternatif yok. Yani önümüzdeki birkaç yıl boyunca hepimiz SQL kullanacağız.

Söylenen her şeyin yanı sıra, bir soyutlama katmanını değerli kılmak için bir teknolojinin kötü olması gerekmez .

Çok basit bir komut dosyası veya uygulama yapıyorsanız, SQL çağrılarını kodunuzda istediğiniz yerde karıştırabilirsiniz. Bununla birlikte, karmaşık bir sistem yapıyorsanız, veritabanı çağrılarını ayrı modüllerde izole etmek iyi bir uygulamadır ve bu nedenle SQL kodunuzu izole etmektir. Kodunuzun okunabilirliğini, sürdürülebilirliğini ve test edilebilirliğini geliştirir. Tüm üst düzey şeyleri vb. Parçalamadan sisteminizi veritabanı modelindeki değişikliklere hızlı bir şekilde uyarlamanıza olanak tanır.

SQL harika. Üzerindeki soyutlama katmanları onu daha da büyütüyor!

Soyutlama katmanlarının bir noktası, standart biraz belirsiz olduğu için SQL uygulamalarının birbiriyle az çok uyumsuz olma eğiliminde olması ve ayrıca çoğu satıcının oraya kendi (standart olmayan) ekstralarını eklemiş olmasıdır. Yani, bir MySQL DB için yazılmış SQL, örneğin bir Oracle DB ile çok benzer şekilde çalışmayabilir - "gerekse" bile.

Yine de, SQL'in birçok soyutlama katmanından çok daha iyi olduğuna katılıyorum. Bunun için tasarlanmadığı şeyler için kullanılması SQL'in hatası değil.

SQL birkaç kaynaktan rahatsız oluyor:

• Zorunlu bir dil dışında hiçbir şey konusunda rahat olmayan programcılar.
• Birçok uyumsuz SQL tabanlı ürünle günlük olarak uğraşmak zorunda olan danışmanlar
• İlişkisel olmayan veritabanı satıcıları, piyasadaki ilişkisel veritabanı satıcılarının hakimiyetini kırmaya çalışıyor
• Mevcut SQL uygulamalarını yetersiz gören Chris Date gibi ilişkisel veritabanı uzmanları

Bir DBMS ürününe sadık kalırsanız, o zaman SQL DB'lerin, en azından modelde bir ölçeklenebilirlik engeline ulaşana kadar, rakiplerinden daha çok yönlü ve daha yüksek kalitede olduğuna kesinlikle katılıyorum. Ama gerçekten bir sonraki Twitter'ı yazmaya mı çalışıyorsun yoksa sadece bazı muhasebe verilerini düzenli ve tutarlı tutmaya mı çalışıyorsun?

SQL eleştirisi, genellikle RDBMS'lerin eleştirilerinin bir dayanağıdır. RDBMS'leri eleştirenlerin anlamadığı şey, büyük bir bilgi işlem problemi sınıfını oldukça iyi çözdükleri ve hayatlarımızı daha zor değil, kolaylaştırmak için burada olduklarıdır.

SQL'in kendisini eleştirme konusunda ciddiyseler, Tutorial D ve Dataphor gibi çabaları desteklerlerdi.

O kadar da kötü değil. Bu sektörde, yeni bir "paradigma" ortaya çıktığında önceki güvenilir teknolojiyi çöpe atmak talihsiz bir eğilim. Günün sonunda, bu çerçeveler büyük olasılıkla veritabanıyla iletişim kurmak için SQL kullanıyor, bu yüzden bu nasıl bu kadar kötü olabilir? Bununla birlikte, "standart" bir soyutlama katmanına sahip olmak, geliştiricinin SQL koduna değil uygulama koduna odaklanabileceği anlamına gelir. Böyle standart bir katman olmadan, bir sistem geliştirdiğiniz her seferde muhtemelen hafif bir katman yazarsınız, bu da çaba israfıdır.

SQL, SET tabanlı verilerin yönetimi ve sorgulanması için tasarlanmıştır. Genellikle daha fazlasını yapmak için kullanılır ve uç vakalar bazen hayal kırıklığına yol açar.

SQL'in gerçek kullanımı, temel veritabanı tasarımından O kadar etkilenebilir ki, sorun SQL olmayabilir, ancak tasarım olabilir - ve kötü bir tasarımla ilişkili eski kodu attığınızda, değişiklikler daha etkisiz ve uygulanması maliyetlidir ( kimse geri dönüp "çalışan" ve hedefleri karşılayan şeyleri "düzeltmeyi" sevmez)

Marangozlar çekiçle çivi çakabilir, keresteyi testereyle kesebilir ve tahtaları düzleştirebilir. Çekiçler ve uçaklar kullanarak "görmek" mümkündür, ancak bu sinir bozucu.

Korkunç olduğunu söylemeyeceğim. Bazı görevler için uygun değil. Örneğin: SQL ile iyi bir prosedür kodu yazamazsınız. Bir zamanlar SQL ile set manipülasyonu ile çalışmaya zorlandım. Bunu anlamak bütün bir haftasonunu aldı.

SQL ilişkisel cebir için tasarlanmıştır - kullanılması gereken yer burasıdır.

Son zamanlarda SQL'in berbat bir dil olduğunu çok duydum ve görünüşe göre güneşin altındaki her çerçeve bir veritabanı soyutlama katmanı ile önceden paketlenmiş olarak geliyor.

Bu katmanların yalnızca kendi öğelerini SQL. Çoğu veritabanı satıcısı SQLiçin motorla iletişim kurmanın tek yolu budur.

Deneyimlerime göre SQL, veri giriş ve çıkışını yönetmenin genellikle çok daha kolay, daha çok yönlü ve daha programcı dostu bir yoludur. Kullandığım her soyutlama katmanı, gerçek bir faydası olmayan, belirgin şekilde sınırlı bir yaklaşım gibi görünüyor.

… Yukarıda anlattığım neden.

Veritabanı katmanları yok eklemek şey, sadece sınırlamak seni. Sorguları tartışmalı şekilde daha basit hale getirirler, ancak asla daha verimli hale getirmezler.

Tanım olarak, veritabanı katmanlarında içinde olmayan hiçbir şey yoktur SQL.

Bu SQLkadar korkunç yapan nedir ve veritabanı soyutlama katmanları neden değerlidir?

SQL güzel bir dil, ancak onunla çalışmak için biraz kafa karıştırıcı gerekiyor.

Teoride, SQL açıklayıcıdır, yani ne almak istediğinizi beyan edersiniz ve motor bunu mümkün olan en hızlı şekilde sağlar.

Pratikte, doğru bir sorguyu formüle etmenin birçok yolu vardır (bu, doğru sonuçları döndüren sorgu).

İyileştiriciler, önceden tanımlanmış bazı algoritmalardan bir Lego kalesi inşa edebilirler (evet, çokturlar), ancak yeni algoritmalar yapamazlar. SQLOnlara yardımcı olmak için hala bir geliştirici gerekiyor.

Ancak, bazı insanlar optimize edicinin "mümkün olan en iyi planı" üretmesini bekler, "bu sorgu için mevcut olan en iyi planı, SQL motorun .

Ve hepimizin bildiği gibi, bilgisayar programı insanların beklentilerini karşılamadığında, suçlanan programdır, beklentiler değil.

Ancak çoğu durumda, bir sorguyu yeniden formüle etmek gerçekten de mümkün olan en iyi planı üretebilir. Bununla birlikte, yeni ve artan iyileştirmelerle birlikte, imkansız olduğu görevler vardır.SQL bu vakalardaki .

Yine de rowid, Cderleyicilerin derlemeyi doğrudan dile yerleştirmenize izin vermesi gibi , satıcılar "dizin aralığını elde etme", "satıra göre bir satır alma " gibi işlevlere bazı düşük düzeyli erişim sağlasaydı iyi olurdu .

Yakın zamanda blogumda bununla ilgili bir makale yazdım:

• SQL'de çift düşünme

Büyük bir ORM savunucusuyum ve yine de SQL'in çok yararlı olduğuna inanıyorum, ancak onunla korkunç şeyler yapmak kesinlikle mümkün (tıpkı her şey gibi). .

SQL'e, kodun yeniden kullanımı veya bakımı / yeniden düzenlenmesi öncelikli olmayan süper verimli bir dil olarak bakıyorum.

Bu nedenle yıldırım hızında işlem önceliklidir. Ve bu kabul edilebilir. Benim için önemli olan değiş-tokuşların farkında olmalısın.

Estetik bir bakış açısına göre, bir dil olarak, OO kavramlarına sahip olmadığı için bazı şeylerden yoksun olduğunu hissediyorum - bana çok eski usul prosedür kodu gibi geliyor. Ancak, belirli şeyleri yapmanın en hızlı yolu çok uzaktır ve bu güçlü bir niş!

Bir çerçeveye dahil edilen bir veritabanı soyutlama katmanının iyi bir şey olduğunu söyleyebilirim çünkü çok önemli iki sorunu çözüyor:

1. Kodu farklı tutar. SQL'i, genellikle çok ince olan ve yalnızca temel sorgulama ve sonuçların aktarımını yapması gereken (standart bir şekilde) başka bir katmana koyarak, uygulamanızı SQL karmaşasından uzak tutarsınız. Bu, web geliştiricilerinin CSS ve Javascript'i ayrı dosyalara koymalarıyla aynı nedendir. Bundan kaçınabiliyorsanız, dillerinizi karıştırmayın .

2. Birçok programcı SQL kullanmakta düpedüz kötüdür. Sebep ne olursa olsun, çok sayıda geliştirici (özellikle web geliştiricileri) SQL veya genel olarak RDBMS'leri kullanmakta çok ama çok kötü görünüyor. Veritabanını (ve uzantıya göre SQL'i) verilere ulaşmak için geçmeleri gereken küçük, küçük aracı olarak ele alırlar. Bu, indeksleri olmayan son derece zayıf düşünülmüş veritabanlarına, şüpheli şekillerde tabloların üstüne yığılmış tablolara ve çok kötü yazılmış sorgulara yol açar. Daha da kötüsü, çok genel olmaya çalışırlar (Uzman Sistem, kimse?) Ve verileri anlamlı bir şekilde makul bir şekilde ilişkilendiremezler.

Ne yazık ki, bazen bir kişinin bir sorunu çözmeye çalışması ve cehalet, inatçılık veya başka bir özellik nedeniyle kullandıkları araçlar birbirleriyle doğrudan zıtlık içindedir ve onları buna ikna etmeye çalışırken iyi şanslar. Bu nedenle, sadece iyi bir uygulama olmanın yanı sıra, bir veritabanı soyutlama katmanını bir tür güvenlik ağı olarak görüyorum, çünkü yalnızca SQL'i zayıf geliştiricinin gözünden uzak tutmakla kalmıyor, aynı zamanda kodlarının yeniden düzenlenmesini önemli ölçüde kolaylaştırıyor, çünkü tüm sorgular tek bir yerde.

SQL, özellikle manipüle etme ve alma gibi belirli görev türleri için mükemmeldir veri kümelerini .

Bununla birlikte, SQL, değişimi ve karmaşıklığı yönetmek için birkaç önemli aracı eksiktir (veya yalnızca kısmen uygular):

• Kapsülleme : SQL'in kapsülleme mekanizmaları kabadır. SQL kodu yazarken, verilerinizin uygulanması hakkında her şeyi bilmeniz gerekir. Bu soyutlama miktarını sınırlar , elde edebileceğiniz .

• Polimorfizm : Aynı işlemi farklı tablolarda gerçekleştirmek istiyorsanız, kodu iki kez yazmanız gerekir. (Bu, görüşlerin yaratıcı kullanımıyla hafifletilebilir.)

• Görünürlük kontrolü : Kodun parçalarını birbirinden gizlemek veya bunları mantıksal birimler halinde gruplamak için standart bir SQL mekanizması yoktur, bu nedenle her tabloya, prosedüre vb. İstenmediğinde bile her birinden erişilebilir.

• Modülerlik ve Sürüm Oluşturma

Son olarak, CRUD işlemlerini SQL'de manuel olarak kodlamak (ve kodu kişinin uygulamasının geri kalanına bağlamak için yazmak) tekrar eder ve hataya açıktır.

Modern bir soyutlama katmanı, tüm bu özellikleri sağlar ve yıkıcı, tekrarlayan uygulama ayrıntılarını gizlerken en etkili olduğu yerde SQL'i kullanmamıza izin verir. Nesne yönelimli yazılım geliştirmede veri erişimini zorlaştıran nesne-ilişkisel empedans uyumsuzluğunun üstesinden gelmeye yardımcı olacak araçlar sağlar .

SQL, Set Teorisine dayanmaktadır, ancak bugünlerde çoğu yüksek seviyeli dil nesne yönelimli. Nesne programcıları genellikle nesneler üzerinde düşünmeyi severler ve nesnelerini depolamak için Set tabanlı araçları kullanmak için zihinsel bir değişim yapmak zorundadırlar. Genel olarak, SQL sorguları yazmak ve elde etmek için veritabanını çağırmak yerine, kendi seçtikleri dilde kodu kesmek ve uygulama kodunda object.save veya object.delete gibi bir şey yapmak çok daha doğaldır (OO programcısı için) aynı sonuç.

Elbette, bazen karmaşık şeyler için SQL'in kullanımı daha kolay ve daha verimlidir, bu nedenle her iki tür teknolojiyi de kontrol etmek iyidir.

IMO, insanların SQL ile yaşadıklarını gördüğüm sorunun ilişkisel tasarımla veya SQL dilinin kendisiyle ilgisi yok. Birçok yönden temelde bir iş katmanı veya arayüzü modellemekten farklı olan veri katmanını modelleme disiplini ile ilgilidir. Sunum katmanındaki modellemedeki hataları düzeltmek, genellikle veritabanını kullanan birden çok uygulamanızın olduğu veri katmanına göre çok daha kolaydır. Bu sorunlar, hizmetinizin mevcut tüketicilerini ve girdi ve çıktı sözleşmelerini hesaba katmanız gereken SOA tasarımlarında bir hizmet katmanı modellemede karşılaşılanlarla aynıdır.

SQL, ilişkisel veritabanı modelleriyle etkileşim kurmak için tasarlanmıştır. Bir süredir var olan başka veri modelleri de vardır, ancak veri katmanını tasarlama disiplini, kullanılan teorik modelden bağımsız olarak doğru şekilde mevcuttur ve bu nedenle, geliştiricilerin tipik olarak SQL ile yaşadığı zorluklar genellikle ilişkisel olmayan ilişkisel bir veritabanı ürününe veri modeli.

Öncelikle, sizi SQL enjeksiyon saldırılarından koruyarak parametreleştirilmiş sorguları kullanmayı önemsiz hale getiriyorlar. Bu açıdan ham SQL kullanmak daha risklidir, yani güvenlik açısından yanlış yapmak daha kolaydır. Ayrıca, veritabanınızda genellikle nesne odaklı bir bakış açısı sunarak sizi bu çeviriyi yapmak zorunda bırakmazlar.

Son zamanlarda çok duydun mu? Umarım bunu NoSql hareketiyle karıştırmıyorsunuzdur. Bildiğim kadarıyla, bunun esas olarak yüksek ölçeklenebilir web uygulamaları için NoSql kullanan ve SQL'in "yüksek ölçeklenebilirlikli web uygulaması" olmayan bir senaryoda etkili bir araç olduğunu unutmuş görünen bir grup insan olduğunu biliyorum.

Soyutlama katmanı işi, Nesneye Yönelik kod ile SQL gibi Tablo Kümesi tabanlı kod arasındaki farkı çözmekle ilgilidir. Genellikle bu, çok sayıda kazan plakası ve ikisi arasında donuk geçiş kodu yazılmasına neden olur. ORM bunu otomatikleştirir ve böylelikle objektif iş insanları için zaman kazandırır.

Deneyimli SQL programcısı için kötü taraflar

• lâf salatası
• Birçoğunun burada söylediği gibi, SQL bildirimseldir, yani optimizasyon doğrudan değildir . Pist yarışına kıyasla ralli gibi.
• Olası tüm lehçeleri ele almaya çalışan ve bunların hiçbirinin kısayollarını desteklemeyen çerçeveler
• Kolay sürüm kontrolü yok.

Diğerleri için sebepler şudur:

• bazı programcılar SQL'de kötüdür. Muhtemelen SQL setlerle çalıştığı için, programlama dilleri nesne veya işlevsel paradigma içinde çalışır. Setler halinde düşünme (birlik, ürün, kesişme), bazı insanların sahip olmadığı bir alışkanlık meselesidir.
• bazı işlemler kendi kendini açıklayıcı değildir: yani ilk başta, nerede ve farklı kümeleri filtrelemeye sahip olduğu net değildir .
• çok fazla lehçe var

SQL çerçevelerinin birincil amacı, yazımınızı azaltmaktır. Bir şekilde yaparlar, ancak çoğu zaman yalnızca çok basit sorgular için. Karmaşık bir şey yapmayı denerseniz, dizeleri kullanmanız ve çok yazmanız gerekir. SQL Alchemy gibi mümkün olan her şeyi işlemeye çalışan çerçeveler, başka bir programlama dili gibi çok büyük hale gelir.

[26.06.10 tarihinde güncelleme] Son zamanlarda Django ORM modülüyle çalıştım . Bu, gördüğüm tek değerli SQL çerçevesi. Ve bu, eşyalarla çalışmayı çok kolaylaştırıyor. Karmaşık kümeler biraz daha zordur.

SQL kötü bir dil değil, bazen başkalarıyla pek iyi oynamıyor.

Örneğin, tüm varlıkları bir OO dilinde veya başka bir dilde nesneler olarak temsil etmek isteyen bir sisteminiz varsa, bunu herhangi bir soyutlama katmanı olmadan SQL ile birleştirmek oldukça külfetli hale gelebilir. OO dünyasında karmaşık bir SQL sorgusunu eşlemenin kolay bir yolu yoktur. Bu dünyalar arasındaki gerilimi hafifletmek için ek soyutlama katmanları eklenir (örneğin bir OR-Eşleştiricisi).

SQL, veri işleme için gerçekten iyi bir dildir. Geliştirici perspektifinden, benim hoşuma gitmeyen şey, veritabanını değiştirmenin derleme zamanında kodunuzu bozmamasıdır ... Bu yüzden, performans fiyatına ve belki de SQL dilinin ifade gücüne bu özelliği ekleyen soyutlama kullanıyorum. çünkü çoğu uygulamada SQL'in sahip olduğu her şeye ihtiyacınız yoktur.

SQL'den nefret edilmesinin bir diğer nedeni de ilişkisel veritabanlarıdır.

CAP Teoremi popüler hale:

Paylaşılan bir veri sisteminden hangi hedefleri isteyebilirsiniz?

• Güçlü Tutarlılık: tüm istemciler, güncellemelerin varlığında bile aynı görünümü görür
• Yüksek Kullanılabilirlik: tüm istemciler, arıza durumunda bile verilerin bazı kopyalarını bulabilir
• Bölme toleransı: sistem bölümlenmiş olsa bile sistem özellikleri korunur

Teorem, aynı anda üç CAP özelliğinden sadece ikisine sahip olabileceğinizi belirtir.

İlişkisel veritabanı, Güçlü Tutarlılık ve Bölme Toleransı'nı ele alır.

Dolayısıyla, giderek daha fazla insan ilişkisel veritabanının sihirli değnek olmadığını anlıyor ve giderek daha fazla insan, yüksek kullanılabilirlik lehine onu reddetmeye başlıyor, çünkü yüksek kullanılabilirlik yatay ölçeklemeyi daha kolay hale getiriyor. Yatay ölçeklendirme , Moore yasasının sınırına ulaştığımız için popülerlik kazanıyor , bu nedenle ölçeklendirmenin en iyi yolu, daha fazla makine eklemektir.

İlişkisel veritabanı reddedilirse, SQL de reddedilir.

Buradaki diğer bazı posterlerin de belirttiği gibi SQL'in birçok kusuru vardır. Yine de, insanların alternatif olarak sunduğu birçok araç yerine SQL kullanmayı tercih ederim, çünkü "basitleştirmeler" genellikle basitleştirmeleri gereken şeyden daha karmaşıktır.

Benim teorim, SQL'in bir grup fildişi kuleli mavi kayakçı tarafından icat edilmiş olmasıdır. Tüm prosedür dışı yapı. Kulağa harika geliyor: Nasıl yapmak istediğini değil ne istediğini söyle. Ancak pratikte sadece adımları atmak genellikle daha kolaydır. Genellikle bu, işiniz bittiğinde arabanın nasıl çalışması gerektiğini açıklayarak araba bakım talimatları vermeye çalışmak gibi görünür. Evet, "Arabanın bir kez daha galon başına 30 mil gitmesini ve böyle bir uğultu sesiyle koşmasını istiyorum ... hmmmm ... ve vb." Diyebilirsiniz. Ama bu herkesin sadece "bujileri değiştirin" mi? Ve karmaşık bir sorguyu yordamsal olmayan terimlerle nasıl ifade edeceğinizi anlasanız bile, veritabanı motoru genellikle oraya ulaşmak için çok verimsiz bir yürütme planı ile gelir.

Ve sıfırların ele alınması beni deli ediyor! Evet, teorik olarak birisi şöyle dediğinde kulağa harika gelmiş olmalı: "Boş değer bilinmeyen anlamına geliyorsa, o zaman bilinen bir değere bilinmeyen bir değer eklemek bilinmeyen bir değer vermelidir. Sonuçta, tanım gereği bilinmeyen değerin ne olduğu hakkında hiçbir fikrimiz yok ." Teorik olarak kesinlikle doğru. Uygulamada, 10.000 müşterimiz varsa ve 9,999'un bize ne kadar borcumuz olduğunu tam olarak biliyorsak, ancak sonuncunun borçlu olduğu miktar hakkında bazı sorular var ve yönetim "Alacak toplam hesaplarımız nedir?" Diyorsa, evet, matematiksel olarak doğru cevap "bilmiyorum". Ancak pratik cevap "4.327.287.42 $ 'ı hesaplıyoruz, ancak bir hesap söz konusu olduğundan bu sayı kesin değildir". Eminim yönetim, belli bir sayı olmasa bile, boş bir bakıştan çok yaklaşmayı tercih eder.

Tüm bunlar, SQL üzerine kurulu bir katmandan ziyade, öğrenmem gereken başka bir dizi şey oluşturan SQL kullanmayı tercih ederim ve sonunda bunun SQL'e çevrileceğini bilmeliyim ve bazen Sadece çeviriyi doğru ve verimli bir şekilde yapacağına güvenebilirim, ancak işler karmaşıklaştığında yapamıyorum, bu yüzden şimdi fazladan katmanı bilmem gerekiyor, yine de SQL'i bilmeliyim ve bunun nasıl tercüme edileceğini bilmeliyim katmanı kandırarak doğru şeyi yapması için SQL'i kandırabilirim. Arggh.

• Her satıcı SQL sözdizimini ihtiyaçlarına göre genişletir. Dolayısıyla, oldukça basit şeyler yapmıyorsanız, SQL kodunuz taşınabilir değildir.

• SQL sözdizimi ortogonal değildir; örneğin, select, insert, update,ve deleteifadelerinin tümü tamamen farklı sözdizimsel yapıya sahiptir.

Puanlarınıza katılıyorum, ancak sorunuzu yanıtlayacak olursak, SQL'i bu kadar "korkunç" yapan bir şey, veritabanı satıcıları (Sql Server, Oracle vb.) Arasında T-SQL'in tam bir standardizasyonunun olmamasıdır ve bu da SQL kodunu tamamen taşınabilir. Veritabanı soyutlama katmanları, bir performans maliyetiyle (bazen çok ciddi bir maliyetle) de olsa bu sorunu çözer.

Saf SQL ile yaşamak gerçekten bir bakım cehennemi olabilir. Benim için ORM'lerin en büyük avantajı, sıkıcı "DB yeniden düzenleme" prosedürleri olmadan kodu güvenli bir şekilde yeniden düzenleme becerisidir. OO dilleri için iyi birim test çerçeveleri ve yeniden düzenleme araçları var, ancak yine de Resharper'ın SQL karşılığını görmem gerekiyor.

Yine de tüm DAL'ların perde arkasında SQL vardır ve veritabanınıza ne olduğunu anlamak için yine de bilmeniz gerekir, ancak iyi soyutlama katmanıyla günlük çalışmak daha kolay hale gelir.

SQL'i çok fazla kullanmadıysanız, en büyük sorunun iyi geliştirici araçlarının olmaması olduğunu düşünüyorum.

SQL ile çok fazla deneyiminiz varsa, bir noktada, yürütme planı üzerinde kontrol eksikliğinden dolayı hayal kırıklığına uğrayacaksınız. Bu, SQL'in satıcılara belirtilme biçiminde doğal bir sorundur. Bence temel teknolojiyi (ki bu çok güçlü) gerçekten kullanmak için SQL'in daha sağlam bir dil olması gerekiyor.

Çabuk, MySQL, Oracle, MSSQL, PostgreSQL ve DB2'de çalışan bir veri kümesini sayfalandırmak için bana SQL yazın.

Oh, doğru, standart SQL, geri gelen sonuçların sayısını ve hangi satırdan başlayacağını sınırlamak için herhangi bir operatör tanımlamaz.

SQL söz dizimi, anlambilim ve güncel kullanım açısından kötü olduğu için SQL sevgisi yoktur. Açıklayacağım:

• sözdizimi bir cobol şarapnelidir, tüm cobol eleştirisi burada geçerlidir (daha az ölçüde, adil olmak gerekirse). Doğal dili yorumlamaya çalışmadan doğal bir dil olmaya çalışmak, rastgele sözdizimi (DROP TABLE veya DROP, UPDATE TABLE, UPDATE veya UPDATE IN, DELETE veya DELETE ...) ve SELECT gibi sözdizimsel canavarlıklar yaratır (kaç sayfa yapar) doldurur mu?)
• Anlambilim de derinden kusurludur, Date bunu ayrıntılı olarak açıklar, ancak üç değerli bir boole mantığının, bir satırın yalnızca bir tablonun parçası olabileceği veya olamayacağı bir ilişkisel cebire gerçekten uymadığını not etmek yeterli olacaktır.
• Veritabanlarının ana (ve genellikle tek) arayüzü olarak bir programlama diline sahip olmak gerçekten kötü bir seçim olduğunu kanıtladı ve yeni bir güvenlik kusurları kategorisi yarattı

Buradaki gönderilerin çoğuna katılıyorum, SQL'in faydası konusundaki tartışmalar çoğunlukla özneldir, ancak iş ihtiyaçlarınızın doğası gereği daha öznel olduğunu düşünüyorum.

Stefan Steinegger'in işaret ettiği gibi, bildirimsel diller, onu nasıl yapmak istediğinizi değil, ne istediğinizi belirlemede iyidir. Bu, çeşitli SQL uygulamalarınızın üst düzey bir perspektiften iyi olduğu anlamına gelir: yani, tek istediğiniz veri almaksa ve başka hiçbir şey önemli değilse, nispeten basit sorgular yazarak ve SQL uygulamasını seçerek kendinizi tatmin edebilirsiniz. bu sizin için doğru.

Çok "daha düşük" bir seviyede çalışıyorsanız ve hepsini kendiniz optimize etmeniz gerekiyorsa, bu ideal olmaktan uzaktır. Daha fazla soyutlama katmanı kullanmak yardımcı olabilir, ancak gerçekten yapmaya çalıştığınız şey, sorguları vb. Optimize etmek için yöntemler belirlemekse, optimize etmeye çalışırken bir aracı eklemek biraz mantıksızdır.

SQL ile yaşadığım en büyük sorun diğer "standartlaştırılmış" diller gibi, çok az gerçek standart var. Neredeyse Sybase ve MySQL arasında yepyeni bir dil öğrenmeyi tercih ederim, böylece iki kuralı karıştırmayayım.

SQL işi hallederken kesinlikle sorunları var ...

• aynı anda hem yüksek hem de düşük seviye soyutlama olmaya çalışıyor ve bu ... tuhaf. Belki de farklı düzeylerde iki veya daha fazla standart olmalıydı.
• standart olarak büyük bir başarısızlık . Bir standart her şeyi karıştırdığında, çok fazla uygulama istediğinde, çok az şey istediğinde veya bazı nedenlerden dolayı satıcıları ve uygulayıcıları tam anlamıyla uyumlu birlikte çalışabilir tam uygulamalar üretmeye motive etme gibi kısmen sosyal hedefi başaramadığında birçok şey ters gider. Kesinlikle SQL'in bunları yaptığını söyleyemezsiniz. Diğer bazı standartlara bakın ve standardın başarılı veya başarısız olmasının, elde edilen faydalı işbirliğinin açıkça bir faktörü olduğuna dikkat edin:
  • RS-232 ( Kötü , neredeyse yeterince belirtilmemiş, hangi pinin ilettiği ve hangi pinin alacağı isteğe bağlıdır. Uyumlu olabilir ama yine de hiçbir şey elde edemezsiniz. Başarılı birlikte çalışma şansı: IBM PC fiilen kullanışlı bir standart yapana kadar gerçekten düşük .)
  • IEEE 754-1985 Kayan Nokta ( Kötü , aşırı erişim: tek bir süper bilgisayar veya bilimsel iş istasyonu veya RISC mikroişlemcisi onu benimsemedi, ancak sonunda 20 yıl sonra onu HW'de güzel bir şekilde uygulayabildik. En azından sonunda dünya ona doğru büyüdü.)
  • C89, C99, PCI, USB, Java ( İyi , ister standart ister spesifik olsun, hemen hemen herkesten katı uyumu motive etmeyi başardılar ve bu uyumluluk başarılı bir birlikte çalışmayla sonuçlandı.)
• tartışmasız dünyanın en önemli veri tabanı olarak seçilemedi . Bu, bir nedenden çok bir veri noktası olsa da, Google Bigtable'ın SQL olmaması ve ilişkisel olmaması, SQL için bir tür anti-başarıdır.

SQL'den hoşlanmıyorum ama geliştirmekte olduğum şeyin bir parçası olarak da yazmak zorunda kalmak istemiyorum. DAL, pazarlama hızı ile ilgili değildir - aslında, koddan doğrudan sorgulardan daha hızlı olacak bir DAL uygulaması olacağını hiç düşünmemiştim. Ancak DAL'ın amacı soyutlamaktır . Soyutlamanın bir bedeli vardır ve işte uygulanması daha uzun sürecektir.

Yine de faydalar çok büyük. Kod etrafında yerel testler yazmak, ifade edici sınıflar, güçlü bir şekilde yazılmış veri kümeleri vb. Kullanarak, C # 'da Generics kullanan saf bir DDD uygulaması olan "DAL" türlerini kullanıyoruz. Dolayısıyla, jenerik depolarımız, iş birimi uygulamalarımız (kod tabanlı işlemler) ve mantıksal ayırma var. Veri kümelerimizi çok az çabayla modellemek ve aslında veritabanı uygulamalarından önce geliştirmek gibi şeyler yapabiliriz. Böyle bir çerçeve oluşturmanın önceden bir maliyeti vardı, ancak çok güzel iş mantığının yine gösterinin yıldızı. Verileri artık bir kaynak olarak kullanıyoruz ve bunu kodda yerel olarak kullandığımız dilde ele alıyoruz. Bu yaklaşımın ek bir yararı, sağladığı net ayrımdır. Örneğin, bir web sayfasında artık veritabanı sorgusu görmüyorum. Evet, o sayfanın veriye ihtiyacı var. Evet, veritabanı işin içinde. Ama şimdi, veriyi nereden alırsam alayım, koda girip onu bulabileceğim bir (ve tek) yer var. Belki daha küçük projelerde büyük bir anlaşma olmayabilir, ancak bir sitede yüzlerce sayfanız veya bir masaüstü uygulamasında düzinelerce pencereniz olduğunda, gerçekten takdir edebilirsiniz.

Bir geliştirici olarak, mantıksal ve analitik becerilerimi kullanarak işin gereksinimlerini uygulamak için işe alındım - ve çerçeve uygulamamız şimdi daha üretken olmamı sağlıyor. Bir yönetici olarak, geliştiricilerimin sorunları çözmek için SQL yazmak yerine mantıksal ve analitik becerilerini kullanmalarını tercih ederim. Geliştirme döngüsünün sonuna yaklaşıncaya kadar veritabanına sahip olmadan veritabanını kullanan bir uygulamanın tamamını oluşturabilmemiz güzel bir şey. Veritabanı uzmanlarına karşı bir saldırı anlamına gelmez. Bazen bir veritabanı uygulaması çözümden daha karmaşıktır. SQL (ve bizim durumumuzda, özellikle Görünümler ve Depolanan İşlemler), kodun verileri bir hizmet olarak tüketebildiği bir soyutlama noktasıdır. Veri ve geliştirme ekipleri arasında kesin ayrımın olduğu mağazalarda, bu, veritabanı uygulaması ve değişiklikleri için bekleme düzeninde oturmayı ortadan kaldırmaya yardımcı olur. Geliştiriciler, bir DBA'nın üzerine gelmeden sorunlu etki alanına odaklanabilir ve DBA, bir geliştiriciye ihtiyaç duymadan doğru uygulamaya odaklanabilirhemen şimdi .

Buradaki birçok gönderi, SQL'in "kod optimizasyonu" özelliklerine sahip olmadığı ve yürütme planları üzerinde hiçbir kontrolünüz olmadığı için kötü olduğunu savunuyor gibi görünüyor.

SQL motorlarının iyi olduğu şey, yazılı bir talimat için, verilere , gerçek içeriğe yönelik bir yürütme planı oluşturmaktır . İşlerin programlama tarafının ötesine bir göz atmaya özen gösterirseniz, verinin uygulama katmanları arasında baytlardan daha fazlası olduğunu göreceksiniz.