Hala SQL yazmaya ihtiyaç var mı?

Çoğu modern dil için çok sayıda ORM aracıyla, bir programda, bunları destekleyen bir dilde / ortamda SQL yazmak ve yürütmek için hala bir kullanım durumu var mı? Öyleyse neden?

Açıklık için: Programcıların SQL bilmeleri gerekip gerekmediğini veya masaüstümde bir SQL aracım olup olmadığını sormuyorum. Özellikle neden ORM yerine kodu (veya config, ya da ne olursa olsun) olabilir soruyorum .

• Veri sorgulamak için SQL yazmak yordamsal kod yazmaktan daha rahat.
• ORM'niz, güzel görünmekle birlikte, bazı kritik alanlarda korkunç derecede yavaş SQL üretir.
• RDBMS'nizin maruz kaldığı ve ORM'niz aracılığıyla sağlanamayan / kullanılamayan işlevlerden yararlanmanız gerekir.
• Her SELECT * FROM...yazdığınızda, Tanrı bir yavru kedi öldürür. Ve kedi yavrularından nefret ediyorsun .
• ORM, OOP veya modern bir dil kullanmıyorsunuz.

Karmaşık SQL yazma

ORM temel şeyler için mükemmeldir. Ancak karmaşık durumlar için SQL yazmanız gerekecektir.

Kısacası, kesinlikle SQL'e ihtiyaç var ve her zaman böyle kalacak.

• Görüntüleme
• tetikleyiciler
• Kısıtlamalar
• Paketler (SSIS, DTS, vb.)
• Yürütme akışını tam olarak kontrol etmeniz gerektiğinde

ORM, veritabanını oluşturmanıza, ayarlamanıza veya otomatikleştirmenize yardımcı olmaz. Sadece tüm bu şeyleri yaptıktan sonra veritabanı ile etkileşim için alternatif bir yol sağlar.

Elbette:

• Genel olarak ORM çok fazla kapsüle girer, ancak sonunda perde arkasında neler olduğunu bilmelisiniz. Bu, performans ve ölçeklenebilirlik için çok önemlidir. Uygulama içinde o kadar SQL yazmama rağmen kabaca SQL veya DDL'nin nasıl göründüğünü biliyorum.
• Doğrudan SQL genellikle salt okunur sorgular yazmak iyidir. ORM sorgu dilinde formüle etmek çok daha kolaydır ve sonuç kümesini de sınırlayabilirsiniz (örneğin 'id from .....').
• ORM sizi SQL'den uzak tutmamalıdır. Ben doğrudan DB-istemcisi (mysql-istemci gibi) geçici sorgular için SQL çok kullanın. Size çok güzel düzgün bir arayüz ve gruplama işlevleri sunar.

ORM'ler, ortak ilişkisel DB uygulamalarımız ile OO dili özellikleri arasındaki empedans uyumsuzluğu nedeniyle mevcuttur. Sadece bir köprüdür, ancak çoğu insan SQL'i buzdolabındaki Limburger peyniri gibi tedavi eder.

SQL / depolanmış yordamları / görünümleri birinci sınıf arayüz (ler) olarak ele almak yerine ORM'nizi veya diğer soyut veri erişim katmanınızı her zaman kullanacağınızı haklı olarak söyleyebiliyorsanız, SQL'e dokunmadan daha iyi durumda olursunuz.

Uygulamada, veritabanını son doğrulama için sorgulamak için en azından SQL gerektirmeyen bir salt ORM projesi görmedim.

ORM'ler programcılar araç kutusundaki bir araçtır. Kendi sorunları var. Bazı örnekler:

• Sql denetlenemiyor
• N + 1 probleminden muzdarip

Ne yaptığınızı biliyorsanız, CRUD tipi kodunuzun çoğunu değiştirmek için etkili bir şekilde bir ORM kullanabilirsiniz. Karmaşık şeyler için o kadar etkili değiller, performans ayarlaması zor (performansın, nesneleri taklit etmenin veritabanı tasarımının kritik parçalarından biri olduğunu biliyorsunuz) ve bunu yapmayan birinin elinde düpedüz korkunç ve tehlikeli SQL'i kendileri anlamıyor veya yazmıyor.

Ayrıca karmaşık raporlamanın bir ORM ile etkili bir şekilde yapılmasının kolay olmadığını belirtmek isterim. Ayrıca, basit SQL'lerde basit SQL'i öğrenmezseniz, raporlama için karmaşık SQL yazabileceğiniz noktaya nasıl ulaşırsınız? Raporlama ihtiyaçları olmayan ve genellikle oldukça karmaşık olan bir uygulamada hiç çalışmadım.

ORM'ler çoğunlukla BI veya ETL süreçleri için yararlı değildir. Ayrıca veritabanı yöneticisi sorguları veya denetim tablolarında bilgi bulmak ve belirli bir veritabanı değişiklikleri kümesini geri almak için de yararlı değildir. SQL ile hala en etkili şekilde yapılan birçok şey var. Veritabanını sorgulayan uygulama, onu Enterprise ortamında sorgulamak için gerekenlerin küçük bir kısmıdır.

Ayrıca posterin SQL'de nasıl yapılacağını bildiği bir ORM kullanarak bir şeylerin nasıl yapılacağı hakkında birçok soru görüyorum. Yeni şeyler öğrenmek güzel, ama orjinal yöntemden (ve çoğu zaman gerçek bir performans kaybından) gerçek bir kazanç olmadan ekstra zaman ve çabaya neden olduklarında, neden bunları şu anda "moda" olduklarından başka kullanıyorsunuz.

Bazen bir müşteri bir rapor, dışa aktarma, veri dökümü vb. İçin veri döndürmek için hızlı ve kolay bir sorgu ister ve tüm programın geliştirilmesini beklemek ister.

Ayrıca, iyi bir SQL programcısı kullandığım herhangi bir ORM'den daha hızlı, daha verimli SQL yazabilir. Ayrıca, birçok insanın ORM'nin saklı yordamlara işaret ettiğini buldum - ORM'nin faydalarını görmezden gelmek, ORM'lerin karmaşık süreçler için harika olmamasına neden oldu.

Ayrıca, çok zengin ve güçlü bir yordam dili ile Oracle gibi bir veritabanı kullanırken, bir "program" a ihtiyaç duymadan çok şey yapabilirsiniz. Doğru ellerde Oracle üzerinde PL / SQL çok hızlı ve etkilidir.

Bir veritabanını kendiniz kullanmak istiyorsanız, evet. Kullanmaya çalıştığım ORM'lerin çoğu yeterli değildi veya veritabanımı kapsamıyordu. Ayrıca, ele alınmayan özel sorguları nasıl giderecek veya yazacaksınız?

Tetikleyiciler ve saklı yordamlar yazmak için hala gereklidir. Saklı yordamlar şu anda gözden düşmüş olabilir, ancak bazı durumlarda hala çok yararlıdır. Bazı kıllı çok masalı birleştirmeler için de SQL gerekebilir.

Evet, SQL yazmaktan kaçınabilirsiniz. Ancak bunun yerine HQL yazacaksınız (veya Linq veya DQL ...)!

Cidden, ben ORM'lerin büyük bir hayranıyım ve birisinin çoğu zaman saf SQL kullanmaktan kaçınabileceğini düşünüyorum. Ama biz bir ORM sadece büyük bir soyutlama olduğunu ve tüm büyük soyutlamalar unutmamalıyız sızıntı ...

(Ancak N + 1 problemi hakkında: bu tembel yüklemeyle ilgilidir ve çoğu ORM aracının istekli yükleme talebinde bulunmanın bir yolu vardır, bu nedenle bu sorunu önler.)

ORM sizi sadece bir noktaya götürür. Ancak, karmaşık birleşimler, alt sorgu, sendikalar, eksi, analitik işlevler vb. İle gerçekten karmaşık bir sorgu yürütmeniz gereken durumlar vardır. Ancak tüm basit sorguları ORM'ye bıraktığınızda nasıl karmaşık sorgular yazmanız gerekiyor?

Kodunuzda yazmanıza gerek olmasa bile, bir veritabanı sunucusuna terminal erişiminiz olduğunda bunu kullanabilmek oldukça kullanışlıdır.

Ayrıca, bir meydan okuma programlama kılan en hayat setleri sık bize-o kısıtlamalar dahilinde çalışmaktadır olan eski kod veya veri tabanlarının eski sürümleri ile çalışan ve biz ne olursa olsun dil için en son ORM kütüphane kurmak için fırsat yok ile çalışan. Bu durumda, elinizin altında herhangi bir alete ihtiyacınız olacaktır.

Geri kalan zamanda CRUD öğeleriniz için SQL'e ihtiyacınız olmayabilir, ancak SQL'de basit SELECT, INSERT, UPDATE ve temel JOIN sorgularından çok daha fazlası vardır. Bununla çok zekice şeyler yapabilirsiniz ve sık sık kullanmasanız da, ne olduklarını bilmek faydalıdır.

Kendimizi giderek SQL dünyasında bulacağımızı düşünüyorum, ancak Bulut hizmetlerinin çoğu sql olmayan tablo depolaması kullanıyor ve basit CRUD tipi işler için SQL'in tüm gücü gereksiz. Ancak bu, onu anlamanın hiçbir değeri olmayacağı anlamına gelmez.

Ayrıca, tabii ki, birisi cari olanlar kadar çok değilse daha iyi bir ORM sistemi yazmak için yeterli bilmek zorunda. SQL'i tanıyorlarsa onlara yardım ederdi ...

Büyük ölçekli web uygulamaları oluşturmak için tamamen gereksizdir ve işleri olması gerekenden çok daha stresli ve zaman kaybına neden olabilir. Bunun nedeni, herhangi bir büyük ölçekli uygulamanın, DB'nin sık kullanılan bellek önbellekleme parçaları olması gereken bir bellek kalıcılık katmanını (RAM'de) kullanmasıdır.

Çalışmak için çok fazla belleğe sahip olmayan mobil cihazlarla vb. Bir şeyler yapmanız gerekiyorsa, programlanan uygulamanın bir mobil cihazda, tablette vb. Bir "istemci" veya bağımsız bir uygulama olarak çalıştığı SQL kullanımı gibi şeyler hala yaygındır ve önemlidir, çünkü cihazdaki bellek o kadar küçüktür ki, bellekteki birçok şeyi önbelleğe alamazsınız.

Yazdığım SQL karmaşıklığı ve miktarı, bir ORM çerçevesini makul bir şekilde takmak için yeterli değildir.

(Ben ayda bir kez belki SQL yazıyorum)

ORM araçlarını kullanarak geliştiricilerden aktif olarak korkan DBA'larla birçok büyük kolordu ile karşılaştım.

Bunlar, ayarlama ve performansa dahil olan DBA'lardır.

Ve evet, ORM araçları böyle şeyler yapmak için yönetilebilir, ancak sadece saklı bir prosedürü (Sql Server) kabul edecekleri ve içinde ne yaptığınızı sorgulayacakları yerler gördüm.

Ayrıca, ORM araçları kötü bir şekilde istismar edilebilir ve Sql'i kendiniz yazmak kadar zayıf Sql üretebilir.

Bir biggie - DDL ve veritabanı geçişleri. Bazen mevcut verileri bozmadan bir şeyleri güncellemek için bu şeyleri elle dikmeniz gerekir.