ORM çerçevelerini iyi tanıyorsam SQL önemli midir? [kapalı]

SQL'de ciddi bir deneyimim yok ve hatta LINQ yerine SQL yazmaktan nefret ediyorum. ORM'ler ile yeterince mutluyum.

İşveren ve sektör açısından bakıldığında, SQL'i bilmek önemlidir? Bu konuda ustalaşmak zorunda mıyım? ORM çerçeveleri üzerinden saf SQL'i tercih eden şirketler, programlama dünyasında bir "dinozor" mu?

Bunu bir çok programcıya açıklamak zordur, çünkü yalnızca temel SQL'i biliyorsanız , bir ORM'nin koltuk değneği üzerinde size pek bir avantaj sağlamaz . Bununla birlikte, daha gelişmiş SQL kavramları, sadece işe yarayan uygulamalar ile yüksek kaliteli uygulamalar (özellikle hızlı ve güvenilir) arasındaki farkın önemli bir parçasıdır .

Başka biriyle farz ediyorum tasarımlar yapıyor, çünkü sizin için veritabanlarını olduğu herhangi bir SQL bilmeden sadece soluk ötesindedir. Ancak, yalnızca onlara karşı gelişiyor olsanız bile, işte ORM'lerin hala kötü bir şekilde yapma eğiliminde olan ya da hiç yapmadıkları şeylerin kısmi bir listesi:

• Özyinelemeli ve / veya hiyerarşi sorguları
• İsteğe bağlı parametreler (özellikle onları aralık tahminlerine çevirme)
• Kullanıcı tanımlı veri tipleri
• Platforma özgü tipler (SQL hiyerarşi ve TVP'ler, Oracle dizileri ve iç içe geçmiş tablolar, vb.)
• Toplu ekler / güncellemeler / upser / siler
• Dizin ipuçları
• Kilitleme ipuçları (özellikle kilitleri ve kirli okumaları güncelle)
• Hata işleme
• Dış birleştirmeler - sonuçları OOP modeline göre zayıf bir harita oluşturur, birçok ORM'nin kendi sorgu dili vardır, ancak bu SQL'in kendisini bilmesine benzer;
• Saklı yordam ve UDF'ler aracılığıyla modülerleştirme, özellikle satır içi UDF'ler ve CROSS APPLY sorguları
• ÇIKIŞ / GERİ DÖNÜŞÜNÜ verilerin birden fazla tabloya yerleştirilmesi için kullanılması
• Verimli çağrı sorguları
• Pencereleme fonksiyonlarına dayalı sorgular (rownum, rank, partitions)

Liste uzayıp gidiyor - bunların çoğu acemi bir DBA'nın asla yapmak zorunda olmadığı şeyler ve acemi bir geliştiricinin hiç duymadığı şeyler - ancak daha büyük ölçekli uygulamalarda çok önemli.

ORM'ler gerçekten sıkıcı SQL kodunu hızlandırmakta gerçekten harika - yani, tekrarlayan tüm CRUD ve haritalama ve diğer tesisat kodlarını, yani onları kullanmakta kesinlikle utanılacak bir şey yok ve kötü olduklarını söyleyen hiç kimseyi dinlemeyin. Fakat kesinlikle hala öğrenmeniz ve evet olmanız gerekir, hatta ana SQL bile ve ORM ağırlığını çekmiyorsa ham DB komutlarını / sorgularını bırakmaya hazır olun.

Kesinlikle! SQL hala veritabanlarının lingua franca'sıdır ve ORM'lerle çok şey yapabilseniz de, ORM'lerin aldığı kararları ve ürettikleri SQL'i anlamak için SQL'i anlamanız gerekir. Ayrıca, özel sql ve saklı yordamlar ile yapmanız gereken birçok şey var. Üzgünüm, bedava yemek yok.

Evet, hala SQL bilmeniz gerekir. ORM'ler çok sızdıran bir soyutlamadır ve SQL'in tam gücüne erişim sağlamaz. İçin oyuncak uygulamaları sınırlı SQL bilgisine sahip Tamam olabilir. Kurumsal uygulamalar için, ORM'den iyi performans elde etmek için veritabanını anlamanız gerekir. Ayrıca, SQL ile bir uygulama diline göre çok daha kolay bir şekilde gerçekleştirilebilen çok sayıda görev vardır. Java programcılarının bir saat içinde SQL'de kodlanmış bir şeyi yapmak için kod yazarak günlerini harcadıklarını gördüm. SQL bilgisi, ilişkisel veritabanı kullanan uygulamalar yazan herkes için çok değerlidir.

SQL becerisi bugün BT'de beceri sahibi olmak zorundadır. LINQ bir Microsoft Only teknolojisidir. SQL kullanımları web ve istemci / sunucu uygulama geliştirmenin ötesine geçer. SQL ile iyi değilseniz, veritabanlarını modelleyemez ve ETL yapamazsınız. Data Warehous ürünleri için ORACLE ve SQL Server'da kullanılan SQL lehçelerine hakim olmanız gerekmeyebilir, ancak standart SQL'i bilmeniz gerekir. SQL temelleri basittir, başlamanıza yardımcı olacak tonlarca malzeme vardır.

Bir SQL veritabanıyla etkileşime giriyorsanız, ORM'nin ürettiği SQL'i anlamalısınız. SQL veritabanlarında bulunan kavramları anlamalısınız ve ORM'nizin sizin için neler yapamayacağını anlamalısınız. ORM'ler hayatı kolaylaştırır (ve evet, bence biri olmadan çalışmak sizi birçok durumda bir dinozor olarak nitelendirir), fakat onlar (bildiğiniz şeyleri soyutlamanız için) araçlardır (koltuk değneği değil) (öğrenmenizi engellemek için).

SQL öğrenmeyi reddederseniz, o zaman bir ORM olan veya olmayan SQL veritabanlarına dokunan hiçbir işiniz olmaz ve başka bir iş bulmanız gerekir.

Çok zor bir ORM hayranı olduğumu ve ORM'nin faydalarını yıllardır duyurduğumu ve neden ORM'nin SQL'i bozduğunu söyleyeceğimi itiraf edeceğim.

FAKAT...

Gerçek dünyada SQL'in tamamen ve tamamen gerekli olduğunu kabul etmeliyim ve her geliştirici iyi bir SQL anlayışına sahip olmalıdır.

SQL procs neredeyse her durumda ORM'den daha hızlıdır. ORM çıktısını çoğu durumda iyimser yapabilmenize rağmen, SQL procs'a yakın bir zamanda gelmesini sağlar.

Bazen, istediğiniz sonucu elde etmek için bazı ağır görev SQL'lerine ihtiyacınız vardır ve bu canavar sorguları SQL işlemlerinde oluşturmak daha kolay ve daha hızlıdır.

Sadece iki parçam.

ORM'nin yarattığı karmaşık bir şeyi optimize etmek zorunda olduğunuzda bir zaman gelecek. Bu noktada, genellikle parçalamak için son derece karmaşık bir sorgu var. Temel bilgileri hiç öğrenmediyseniz, ileri düzeyde SQL ile öğrenmeye nasıl başlayabilirsiniz? Başlayacak kadar bile anlamayacaksın. SQL anlayan bir kişinin elinde ORM - iyi bir araç. Hiç kimseyi tanımayan birisinin elinde ORM var - felaket gerçekleşmeyi bekliyor.

Veritabanlarını anlamak için SQL'in kritik olmasının nedenlerinden biri, uygulama programcılarının doğal olarak veri kümeleri olarak düşünmemeleridir. Ancak veritabanlarının verimli bir şekilde çalışmasının tek yolu kümelerdir. Bir ORM kullanmaya çalışmadan önce setler halinde nasıl düşüneceğinizi öğrenmeniz gerekir.

Kendimi ORM çerçevelerindeki sorguları kendimden daha çok zorlayarak kendimi zorluyorum. Ve çoğu kendi sorgu diline sahip olsa da, hepsi sql'den esinlenmiştir, kod sql'ye dönüşür ve işler ters gittiğinde ya da kötü performans gösterdiğinde, bu sql'yi okuyarak neyin yanlış gittiğini anlamanız gerekir.
Yani doğrudan sql yazmasanız bile, bunu temel bir seviyenin ötesinde anlayın (eğer tek yapmanız gereken saklı yordamlar, tetikleyiciler vb. Yazma hakkında bir şeyler öğrenmenize gerek kalmayacak (tüm yapacağınız veri tabanlarına erişmekse) Oluşturulan kodu anlayacak ve dili gerektiği gibi ayarlayacak dili bilmeli.

Soru hakkında konuşmadan önce ilk önce küçük bir giriş yapın; ORM'leri severim. Ve SQL'den nefret ediyorum. ORM'leri severim çünkü SQL'in kullanıcı dostu olmayan karmaşasını gizliyorlar ve veritabanıyla başa çıkabilmek için dille bütünleşik güzel bir yol sağlıyorlar.

Ancak, SQL’in bir çok faydası olduğunu ve en büyüğünün hassas olduğunu kabul etmeliyim. Bir SQL sorgunun karmaşıklığı hakkında, altta yatan veritabanı şeması hakkında ayrıntılı bilgi olmadan, sadece sorguyu gözden geçirerek tartışabilirim. Bu nedenle, SQL kullandığımda her zaman uyanığım ve her zaman bir bileşenin karmaşıklığının nereye gittiği konusunda bir sezgim var.

Öte yandan, ORM'leri kullanırken, veritabanı entegrasyon kolaylığı beni çok etkiliyor, tam anlamıyla bir veritabanı olduğunu bile unutuyorum. Bu beni defalarca mahvetti. Geçmişte çoğu zaman, masum görünümlü ORM yöntemlerini kullandım, sahnelerin ardında masif ve korkutucu veritabanı birleşmeleri diyor, performansı yok ediyor.

Bu yüzden benim için gerçek, arada bir yerde. ORM'leri kullanmayı seviyorum ve yapmaya devam edeceğim, ancak daha dikkatli olmalı ve her zaman herhangi bir ORM yöntemi çağrısının sonuçlarını (SQL düzeyinde) incelemeliyim. Soyutlama katmanının etkilerini bilmek bu işte saf altındır ve soyutlamanın kullanımını haklı gösterir. Başka bir şey, kendini yaya olarak vurmak gibi.

Yapmanız gereken tek şey, yalnızca oluşturduğunuz uygulama olsa da veritabanıyla etkileşime giriyorsa, büyük olasılıkla buna ihtiyacınız yoktur. Bazı küçük şirketler veya geliştirici ekiplerde, biraz destek yapmanız gerekebilir. Bir müşterinin veritabanına bağlanmak ve verilerinde neler olup bittiğini görmek için birkaç sql ifadesi çalıştırmak çok daha kolaydır.

İyi, olgun bir ORM ile bile, kaçınılmaz olarak, bazı SQL verilerini yayan ve oluşturulan SQL'de olup bitenleri başarabilirseniz hayatınızı çok daha kolaylaştıracak durumlara gireceksiniz. Bununla birlikte, ORM konusunda çok ustalaşırsanız ve seçtiğiniz DB için bir profilleyiciyi nasıl kullanacağınızı biliyorsanız, "kolayca yapana kadar sahte" olabilirsiniz.

Tüm bu tür soruların cevabı ("X'i bilmem gerekiyor mu?"), "İlk defa ihtiyacınız olduğunda, ihtiyacınız olursa, öğren" şeklindedir.

İşleri daha az verimli yapmanın tuzağına düşmemeniz önemlidir, çünkü bunları yapmanın etkili bir yolunu bilmiyor veya öğrenmeye istekli olmuyorsunuz.

Bu özel durumda, örneğin, programınızda PostCountkullanıcı tablonuzun alanının bazen yanlış olmasına neden olan bir hata olduğunu fark ederseniz ne yaparsınız .

Hatayı düzelttiniz ve şimdi tüm kullanıcılar için PostCount'u güncellemelisiniz. Bunu nasıl yapıyorsun?

Bunu yapmak için ORM kullanarak küçük bir senaryo yazarsanız, o zaman çok verimsiz olursunuz; çok basit bir SQL sorgusu yapacağız.

Bu durumlar oldukça yaygın olduğundan, yukarıda açıklanan tuzağa düştüğünüzden korkuyorum!

Evet, hala SQL'e ihtiyacınız var.

“Eski” bir şeyin bir şekilde değerlendirilmeye değer olmadığı varsayımına atlamayın. Sözde "eski" teknolojiler, zamanın testinden sonra hala etrafta olan teknolojilerdir. Wang bilgisayarlarına "miras" demiyoruz, başarısız oldular ve gittiler.

Bana sorarsanız, bankamın muhtemelen bir ana bilgisayarda COBOL veya IBM i kullanması beni rahatsız ediyor mu? Absolutley değil. Bunlar sağlam, denenmiş ve gerçek teknolojilerdir. Tahmin et ne oldu, çoğunlukla DB2 SQL kullanıyorlar. Oradaki paraya güveniyorum, ayın modaya uygun bir dilinde geliştirilen yazılımlardan çok.

Bu dünyadaki dinozorlar, insanların etrafta olduklarından çok daha uzun sürdüler. Jurasic Park'ı okuyorsanız (evet, kitaplar filmlerden daha iyidir) o zaman soruyorum, gerçekten bir paket hiper zeki velocu ya da hiç pes etmeyen dogged T-Rex ile yüzleşmek ister misiniz? "Dinozorları" hafife alarak ısırılmayın. ;-)

Oyun ve deneyimlediğim (çoğunlukla istatistiksel) araştırma dışında, veritabanı erişiminin ve işlemlerinin yanlış kararların çok yüksek performansa neden olduğu birkaç alandan biri olduğu görünüyor. Koddaki daha güçlü veritabanı soyutlamalarına inanıyorum ve veritabanı işlemlerini programlama diline bağlayan linq'in size dilin tüm araçlarını (tip kontrolü, sözdizimi kontrolü, sevdiğiniz her şeyi veren) inanıyorum. programlama dilinizi) hala size ne yapmak istersen onu yapabilecek kadar çok güç verirken kesinlikle müthiş. Ne yazık ki, hala her zaman çalışmıyor. Bu, eğer soyutlama katmanı optimizasyonlarını yanlış yaparsa ve mikrosaniye yerine saniye veya sonucunuz için saniye yerine dakika bekliyor olabilirsiniz. Bunlar çok göze çarpan zamanlar olduğundan, Bunları uzaklaştırmanız gerekir, aksi halde uygulamanız "işe yaramaz": performans uygulamanızın en büyük sorunu olur. Bu, metale daha yakın olmanız ve elle optimize etmeniz gerektiği anlamına gelir.

Büyük veri kümelerini işlemenin elle yaparken örneğin 3 ms, soyutlama katmanının sizin için yapmasına izin verdiğinizde 100 ms sürer, elbette, soyutlama katmanının sizin için yapmasına izin verin, çünkü 30 kat daha yavaş olun, ancak hala (muhtemelen çoğu uygulama için) yeterince hızlısınız. Ancak durumun gerçekliği, elinizde 200 ms'lik tepki süresine sahip olduğunuz optimize edilmiş çözümlere baktığınızda ve soyutlama katmanı sizin için işlediğinde, algoritmanın “sadece” bir 10 kez performansa ulaşması, 2 saniyelik bir gecikme, ve o kadar hızlı değil, acı verici bir şekilde yavaşlamadan, çok fazla şey umursuyorsunuz. İlişkisel veritabanı çözümlerini görmek iyi ölçeklenmiyor, Bunun iki veya üç yıl içinde çözüleceğini sanmıyorum. Bu, daha büyük veritabanları söz konusu olduğunda oldukça uzun bir süre boyunca hala çıplak metale inmeniz gerekeceği veya uygulamanızın çok yavaş olacağı, rakipler için ayağa kalkamayacağı anlamına gelir.