SQL sorgu oluşturucularını kullanmanın avantajları nelerdir?

Ham SQL kullanmak yerine sorgu oluşturucu kullanmanın herhangi bir avantajı var mı?

Örneğin

$q->select('*')
  ->from('posts')
  ->innerJoin('terms', 'post_id')
  ->where(...)

vs:

SELECT * FROM posts WHERE ...

Birçok çerçevenin bu tür soyutlama katmanlarını kullandığını görüyorum, ancak faydalarını anlayamıyorum.

SQL'i bir çerçeve kuyusu aracılığıyla yazmanın soyutlaması, özetler.

El ile SQL yazmak tek başına o kadar da kötü değil, ama kaçmak ve dezenfekte etmek ile ilgili sorunlar almaya başlıyorsunuz ve bu bir karmaşaya dönüşüyor. Bir soyutlama katmanı, kodunuzun temiz olmasını ve çok sayıda mysql_real_escape_string()çağrı veya benzeri içermemesini sağlayan sahne arkasındaki tüm bunları halledebilir .

Ek olarak, bu, farklı SQL lehçelerinin muhasebeleştirilmesini mümkün kılmaktadır. Tüm veritabanları aynı değildir ve anahtar sözcüklerde veya belirli bir işlevin sözdiziminde farklılıklar olabilir. Bir soyutlama katmanı kullanmak, değişkeniniz için doğru sözdizimini dinamik olarak oluşturma yeteneğini getirir.

Bir soyutlama katmanı bir performans isabeti getirse de, karşılığında aldığınız kodun temizliği ve sağlamlığına kıyasla genellikle ihmal edilebilir.

Sorgu oluşturucular benim evcil hayvanımdan nefret ediyor, bu yüzden onları kullanmaktan kaçınmak için kendi Çerçevemi (Apeel) yazdım!

PDO kullanıyorsanız (ki kesinlikle bunu tavsiye ederim) sonra santising sizin için işlenir.

Başka birinin söylediği gibi, veritabanları arasında geçiş yapmayı kolaylaştırsalar da, "En düşük ortak payda" işlevselliğini destekleme eğilimindedirler ve daha gelişmiş özellikler için ya desteklemezler ya da performansları daha düşük olurlar.

1986'dan beri veritabanları ile sistemler geliştiriyorum ve o zamanlar daha iyi performansa ihtiyaç duydukları zaman kullandıkları veritabanını değiştiren bir şirketle nadiren karşılaştım. Daha iyi performans için veritabanlarını değiştiriyorsanız, zamanınızı harcamak daha basittir.

Bir sorgu oluşturucunun qwirks'iyle başa çıkmak için harcanan zaman (daha iyisine geçtiğinizde yeniden öğrenme), SQL'inizi nasıl optimize edeceğinizi öğrenmek için çok daha verimli bir şekilde harcanır.

Her neyse bu yüzden bir tane KULLANMAMAK, bazı insanlar onları seviyor.

Teorik olarak mı? Evet. Glenn Nelson size sıklıkla nasıl yardımcı olacaklarına dikkat çekti . (İyi bir sorgu oluşturucuysa).

Uygulamada? Her zaman teoriye uymaz ve aslında sorunlara neden olabilir. Bazı popüler DBMS'ye karşı bir sorgu oluşturucu kullandığınızı ve her şeyin şeftali olduğunu varsayalım. Daha sonra bir müşteri, seçtiğiniz sorgu oluşturucunun işleyemeyeceği bazı tuhaflıklar içeren DBMS'lerine vurmanızı ister. (Bu sorunu Pervasive'ın daha eski bir sürümüyle çalışmak zorunda kaldığımda vurdum.)

FAKAT! Kesinlikle yapmanız gereken Veri Erişim Katmanı'nı ayırmak ve gerekirse yeni bir tanesini değiştirebilmenizi sağlamaktır. Bu şekilde tüm özellikleri ile o serin sorgu oluşturucu yapabilirsiniz ama söz konusu DB için o garip sözde sql kullanan yeni bir takmanız gerekiyorsa.

Ben sorgu oluşturucu pratik, günlük fayda - kod yeniden kullanımı ve KURU prensibi takip yeteneği olduğunu düşünüyorum.

Sorgu oluşturucu ile SQL'in tekrarlanan kısımlarını yöntemlere koyabilirsiniz. Ve sonra karmaşık SQL oluşturmak için bu yöntemleri kullanın. Örnek olarak, yeniden kullanılabilir JOIN deyimi verilebilir:

function joinTaskWithClient($queryBuilder) {
    $queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
                 ->join('contract', 'client', 'contract.client_id = client.id');
}

Yani kullanım şöyle olurdu:

$queryBuilder->select('client.name')
             ->from('client')
             ->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);

Dikkat edeceğiniz gibi - sorgu oluşturucu ile, SQL dizesini manuel olarak topladığınız durumun aksine, SQL bölümlerini herhangi bir sırayla ekleyebilirsiniz (örn. NEREDEN birinden sonra JOIN kısmı). Ayrıca, amaç ve faydalarını görmek için oluşturucu kalıbını da okuyabilirsiniz .

Kaçmayı ve dezenfekte etmeyi kabul ediyorum, ancak bu sorgu oluşturucu olmadan da elde edilebilir. DB tipi / lehçe soyutlaması ile ilgili olarak - bu pratikte neredeyse hiç kullanılmayan oldukça teorik ve tartışmalı bir faydadır.

benim özel bir SQL oluşturucu ( Dialect ) benioku dosyasına dayalı bir cevap sağlayacaktır

(düz metin izlenir, kitaplığa özgü referanslar kaldırılır)

Gereksinimler

1. Birden çok DB satıcısını destekleyin (örn. MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..)
2. Yeni DB'lere kolayca genişletilebilir (tercihen, uygulamadan bağımsız bir yapılandırma ayarı aracılığıyla)
3. Modülerlik ve uygulamadan bağımsız aktarılabilirlik
4. Esnek ve Sezgisel API

Özellikleri

1. dilbilgisi tabanlı şablonlar
2. özel yumuşak görünümler desteği
3. db soyutlama, modülerlik ve aktarılabilirlik
4. hazırlanmış şablonlar
5. veri çıkışı

Yukarıdaki özellikler ve gereksinimleri bir SQL soyutlama oluşturucu kullanmak nedenlerini kroki düşünüyorum

Yukarıdaki özelliklerin çoğu çoğu SQL oluşturucuları tarafından desteklenmektedir (her ne kadar listelenenlerin hepsini desteklediğini düşünmüyorum)

Kullanım örneği örnekleri:

1. Birden fazla DB satıcısıyla çalışabilen (temel kod değişikliği olmadan) CMS platformu
2. DB satıcısının değişebildiği ve / veya dB şemalarının dinamik olduğu özel uygulama kodu (bu, birçok sorgunun kodlanamayacağı, ancak kodun değişikliklere karşı sağlam olması için yine de yeterince soyutlanması gerektiği anlamına gelir)
3. Üretimde kullanılandan farklı bir DB ile prototip oluşturma (en azından bazı kodlar için yinelenen kod tabanı gerektirir)
4. Uygulama kodu belirli DB sağlayıcısına ve / veya uygulamasına sıkıca bağlı değildir (aynı DB satıcısında bile, örneğin DB satıcısının farklı sürümlerinde), bu nedenle daha sağlam, esnek ve modülerdir
5. Alışılmış birçok sorgu ve veri çıkışı çerçevesi çerçevenin kendisi tarafından ele alınır ve genellikle bu hem en uygun hem de daha hızlıdır

Son olarak, sahip olduğum bir kullanım örneği. temel DB şemasının (wordpress) yapılması gereken veri sorgularının türü için uygun olmadığı bir uygulama inşa ediyordum, ayrıca bazı WP tablolarının (örneğin mesajların) kullanılması gerekiyordu (bu yüzden tamamen yeni tablolara sahip olmak) çünkü tüm uygulama verileri bir seçenek değildi).

Bu durumda, modelin özel / dinamik koşullarla sorgulanabileceği bir MVC benzeri uygulama yapabilmek, sorgulamayı neredeyse bir kabus haline getirmiştir. Birleştirme ile 2-3 tabloya kadar sorgulamayı desteklemeniz gerektiğini ve hangi tablonun neyle birleştirileceğini görmek için koşulları filtrelediğinizi ve ayrıca gerekli takma adlara dikkat ettiğinizi düşünün.

Açıkçası bu bir sorgu soyutlama kullanım örneğiydi ve daha da fazlası, özel yumuşak görünümleri (birleştirilmiş tabloların modele uygun tek bir özel tabloymuş gibi bir araya getirme ) tanımlayabilme yeteneğine (veya en azından büyük ölçüde faydalanmaya) ihtiyaç duyuyordu. . Sonra çok daha kolay, daha temiz, modüler ve esnekti. Başka bir yönde uygulama (kod) ayrıca sorgu soyutlama katmanını (db şeması) normalleştirme aracı olarak kullanmıştır . Bazılarının dediği gibi, geleceğe yönelikti .

Yarın, insanlar bazı ekstra seçeneklere veya verilere ihtiyaç duyduklarına karar verirlerse, bunu birkaç satırda modele eklemek ve iyi çalışırlar. Buna ek olarak, yarın, insanlar artık wordpress'i kullanmak istemediklerine karar verirlerse (uygulama wordpress'e bir eklenti olarak gevşek bir şekilde bağlandığından), birkaç satırdaki modelleri değiştirmek ( sadece tanımı ) nispeten kolaydır. yeni şemaya uyum sağlamak için kod.

Neyi kastettiğimi anla?

Sıklıkla, bu sorguların argümanlarından bazıları sabitlerden ziyade bazı değerlerdir. Şimdi, bunların çoğu aslında kullanıcı formu gönderilerinden türetilmiştir. Bu nedenle SQL enjeksiyon saldırıları için birçok olasılık vardır. Bu nedenle, doğal olarak sorgu oluşumu tam doğrulama gerektirir.

Şimdi, bu geliştiriciye güvenmediğimiz anlamına gelmez, ancak sorgu oluşumu kolay olabilir, ancak her yerde tüm olası doğrulama kontrollerini tekrarlamak bazen bazen yanlışlıkla özleyebileceğiniz veya sorguyu değiştirebileceğiniz, ancak sorguyu değiştirmeyeceğiniz anlamına gelebilir. doğrulama denetimini güncellemeyin. Bazı acemi bu konuda kaçırmanın tüm tehlikelerini bile biliyor olabilir. Bu nedenle, sorgu oluşturucu soyutlaması oldukça önemlidir.

Sorgu oluşturucuların, tabloları seçmenize ve başlık altında SQL oluştururken grafiksel olarak birleşim yapmanıza izin veren GUI uygulamaları olduğunu düşünürdüm, ancak şimdi de sorgu oluşturucularına saf SQL sorguları oluşturmak zorunda kalmamanın bir yolunu sağlayan API'leri çağırdığınızı anlıyorum. SQL tatlarındaki potansiyel farkları kendiniz soyutlayabilirsiniz.

Bu tür sorgu kurucuları kullanmak iyidir , ancak onlara büyük ölçüde güvenen insanların DBA'lara sorma eğiliminde olmadığını düşünüyorum: "hey, bu çok kullandığım bir sorgu, lütfen ondan bir görünüm oluşturun".

Beni yanlış anlamayın.

Ben tablolar değil, görünümler karşı sorgu yazmak gerektiğini düşünüyorum. Güvenlik veya filtreleme için değil, bu iyi nedenlerdir, ancak aynı nedenle arayüzlere karşı kodlamalısınız ve somut sınıflara karşı değil: ayrıştırma. Görüşler "sözleşmeler" gibidir, aynı şekilde arayüzler OOP'ta "sözleşmeler" dir. Temel tabloları değiştirebilirsiniz, ancak görünümleri programcılara aynı "sözleşmeyi" göstermeye zorladığınız sürece kod kırılmamalıdır.

Yine, yanlış anlamayın, sorgu oluşturucuları görünümleri sorgulamak için kullanabilirsiniz, ancak çok sayıda görünüm, sorgu yazma ve DBA'nıza sormanın bir ürünü olan bir olgunlaşma süreci olarak ortaya çıkar: "dostum, bunu oluşturun, lütfen" .

Sorgu yazmamanın, belirli görünümler oluşturma ihtiyacını tespit edemediğini düşünmek yanlış mıyım?

Beni ilgilendiren başka bir şey, acemi programcıların insanın yarattığı en güzel teknoloji parçalarından biri olan SQL'e hakim olmamalarıdır.