Çok fazla Robert C. Martin içeriği okuyordum / izliyorum. Ona katı hal sürücülerinden dolayı SQL'nin gereksiz olduğunu söyleyerek rastladım. Bunu desteklemek için başka kaynaklar ararken, sabit diskler ve yarıiletken sürücüler arasındaki SQL performansının farkını anlatan bir grup rastgele makale alıyorum (ki bunlar ilişkili ama araştırmaya çalıştığım değil).

Sonunda, neye ulaşmak istediğini anlamıyorum. SQL'in yerini No-SQL teknolojisiyle mi değiştiriyor? Bir dosya sistemindeki dosyalarda veri depolamak mı diyor? Yoksa sadece insanların SQLi saldırıları nedeniyle SQL / İlişkisel Veritabanlarını kullanmayı bırakmasını mı istiyor? Korkarım yapmaya çalıştığı noktayı özlüyorum.

Burada bazı linkler vereceğim, böylece onun aklından direkt olarak okuyabilirsiniz:

1. Bobby Tablolar
2. Temiz Mimari Dersi

İlk olarak, SQL'in sistemden tamamen kaldırılması gerektiğini belirtir.

Çözüm. Tek çözüm. SQL sistemden tamamen ortadan kaldırmaktır. SQL motoru yoksa, SQLi saldırısı olamaz.

SQL'i bir API ile değiştirmek hakkında konuşsa da, önceki alıntı ve makalede daha önce söylediklerinden dolayı SQL'i bir API'nin arkasına koymak demek DEĞİLDİR.

Altyapılar konuyla ilgilenmez;

Not: SQL derken, Robert'ın en ilişkisel veritabanları anlamına geldiğinden eminim. Belki hepsi değil, çoğu. Her durumda, çoğu kişi yine de SQL kullanıyor. yani...

Eğer veriyi sürdürmek için SQL kullanılmıyorsa, ne kullanmamız gerekiyor?

Bunu cevaplamadan önce, ayrıca not etmeliyim. Robert, katı hal sürücülerinin, verileri sürdürmek için kullandığımız araçları değiştirmesi gerektiğini vurgulamaktadır. Søren D. Ptæus'un cevabı bunu gösteriyor.

Ayrıca "ama veri bütünlüğü" grubuna da cevap vermeliyim. Bazı araştırmalar sonrasında , Robert datomic gibi işlemsel veritabanlarını kullanmamız gerektiğini söylüyor . Daha sonra CRUD, CR'ye dönüşür (yarat ve oku) ve SQL işlemleri tamamen ortadan kalkar. Veri bütünlüğü elbette önemlidir.

Tüm bunları kapsayan bir soru bulamıyorum. Galiba Robert’ın kurallarına uygun alternatifler arıyorum. Datomik bir değil mi? Bu yönergelere uygun başka hangi seçenekler var? Ve aslında katı hal sürücülerle daha iyi çalışıyorlar mı?

Bob Martin, noktasını daha net hale getirmek için açıkça abartıyor. Ama amacı ne?

Sadece insanların SQLi saldırıları nedeniyle SQL / İlişkisel Veritabanlarını kullanmayı bırakmasını mı istiyor?

Anladığım kadarıyla, o blog yazısında (ilk bağlantınız) Martin insanları SQL kullanmayı bırakmaya ikna etmeye çalışıyor, ancak ilişkisel veritabanlarını değil. Bunlar iki farklı şey .

SQL son derece güçlü bir dildir ve bir dereceye kadar standardize edilmiştir. Çok kompakt bir şekilde, okunabilir, anlaşılabilir, öğrenmesi kolay bir şekilde karmaşık sorgular ve komutlar oluşturmanıza olanak sağlar. Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP veya başka bir şeyi tercih etmeleri farketmeksizin başka bir programlama diline bağlı değildir, bu nedenle çoğu uygulama programcısı için kullanılabilir.

Ancak, bu güç bir bedelle gelir : güvenli SQL sorguları / komutları yazmak, güvenli olmayanları yazmaktan daha zordur. Güvenli bir API, "varsayılan olarak" güvenli sorgular oluşturmayı kolaylaştırmalıdır. Potansiyel olarak güvensiz olanlar daha fazla zihinsel veya en azından daha fazla yazma çabasına ihtiyaç duymalıdır. Bu, IMHO'nun neden Martin’in şimdiki haliyle SQL’e karşı saldırdığını söylüyor.

Sorun yeni değil ve ilişkisel bir veritabanına erişmek için standart SQL'den daha güvenli API'ler var. Örneğin, tanıdığım tüm OR eşleştiricileri böyle bir API sağlamaya çalışıyor (tipik olarak diğer birincil hedefler için tasarlanmış olsalar da). Statik SQL değişkenleri, girdisiz girdi verileriyle herhangi bir dinamik sorgu oluşturmayı zorlaştırır (ve bu yeni bir buluş değildir: genellikle statik SQL kullanan gömülü SQL, yaklaşık 30 yaşındadır).

Ne yazık ki, esnek, standart, olgun, dilden bağımsız ve ayrıca SQL kadar güçlü, özellikle de dinamik SQL olan herhangi bir API bilmiyorum. Bu yüzden, Martin'in “SQL kullanmama” konusundaki önerisini, belirtilen sorunları çözmenin gerçekçi bir yolu olarak düşündüğüm konusunda bazı şüphelerim var. Öyleyse makalesini, doğru bir düşünceyle okudun, yarından itibaren kör bir şekilde takip edebileceğin "en iyi uygulama" olarak değil.

Bob Martin'in düşüncesi tam olarak budur; bir adamın görüşü.

Bir programcının, güvenliği ve performansı hakkında makul bir özen gösterecek kadar iyi yazdığı sistemi anlaması beklenir. Bu, eğer bir SQL veritabanıyla konuşuyorsanız, Bobby Tables web sitesinin yapmasını istediğinizi yaparsınız: girdi verilerinizi dezenfekte edersiniz. Bu, SQL veritabanınızı yeterli performans vaat eden bir makineye koyduğunuz anlamına gelir. Bunları yapmanın çok iyi bilinen ve iyi anlaşılmış yolları vardır ve mutlak güvenlik veya ideal performansı garanti etmemelerine rağmen, başka hiçbir şey yapmaz.

Artık SQL'e ihtiyacımız olmadığı iddiası, çünkü artık SSD'lere sahibiz. Yüksek icatlı sabit diskler henüz mevcut olmadığından SQL icat edilmedi; icat edildi çünkü veri alma kavramlarını ifade etmek için endüstri standardı bir yola ihtiyacımız vardı. İlişkisel veritabanı sistemleri, iş operasyonları için ideal kılan hız ve güvenliğin yanı sıra birçok özelliğe sahiptir; özellikle, ACID . Veri bütünlüğü, en azından hız veya güvenlik kadar önemlidir ve eğer sizde yoksa, kötü verileri güvence altına almanın veya mümkün olduğunca çabuk almanın amacı nedir?

Bir erkeğin histerisini müjde olarak almadan önce, rastgele Internet makaleleri okuyarak değil, kendi şartlarıyla uygulama ve sistem güvenliği ve performansı hakkında bilgi edinmenizi öneririm. Güvenlik, performans ve sağlam sistem tasarımında "bu teknolojiden kaçınmaktan" daha fazlası var.

Mutfak bıçaklarını yasaklamıyoruz çünkü birkaç talihsiz kişi parmaklarını yanlışlıkla onlarla kesmeyi başarır.

Gerçekten ne söylüyor?

SQL'in yerini No-SQL teknolojisiyle mi değiştiriyor?

TL; DR: Evet (sırala)

Daha önce yaptığınız konuşmada, temelde aynı konuya bağladığınızdan daha fazla: "Veri tabanı bir ayrıntıdır. Neden veri tabanlarımız var?" .

Dönen disklerden veri erişimini kolaylaştırmak için veri tabanının geldiğini iddia ediyor, ancak gelecekte "[...] yeni teknoloji ve" kalıcı RAM "olarak adlandırdığı şey sayesinde diskler olmayacak ve bunun daha kolay olacağını söyledi. saklayıcılar veya ağaçlar gibi programcıların kullandığı yapıları kullanarak verileri depolar.

Bir bütün olarak ilişkisel veritabanlarının yeni rekabetlerinden dolayı büyük ölçüde kaybolacağını tahmin etmeye devam ediyor:

Eğer Oracle olsaydım, oldukça korkardım çünkü varlığımın nedeni altımdan buharlaşıyor. [...] Veritabanının var olmasının nedeni yok oluyor.

Muhtemelen hayatta kalan bazı ilişkisel tablolar olacak, fakat şimdi sağlıklı bir rekabet var .

Bu yüzden hayır, onun için sadece SQL enjeksiyonu ile ilgili değil, SQL'in bu konuda kendiliğinden kusurlu olduğunu iddia etmesine rağmen .

Yazarın notu:

Bu yazıda yer alan ifadeler, sadece Robert C. Martin'in bu konudaki görüşünü anlamak ve yazarın fikrini yansıtmamak için yapılan alıntılardır. Daha farklı bir bakış açısı için bkz. Robert Harvey'in cevabı .

SQL bir detaydır. Bir detay bilgisi yayılmamalı.

SQL, kodunuzda gittikçe daha fazla yerde kullanıldığından, kodunuz ona daha fazla bağımlı hale gelir.

Gittikçe daha fazla SQL hilesi öğrenirken, SQL kullanarak daha fazla sorunu çözersiniz. Bu, devam etmek için başka bir API'ye geçmenin sadece çeviriden daha fazlasını gerektirdiği anlamına gelir. Karşılaştığınız problemleri çözmek zorundasınız.

Bunu, Veritabanları arasında bile geçiş yaparak geçiriyorsunuz. Biri fantezi whizzbang özelliği 5 sunar, bu yüzden sadece fantezi whizzbang özelliği 5'in tescilli olduğunu bulmak için bir çok yerde kullanırsınız ve şimdi çok paraya mal olacak bir lisanslama sorununa sahipsiniz. Böylece, özellik 5'i kullandığınız her yerde kazma ve sorunu kendi başınıza çözme, ancak daha sonra whizzbang özelliğini 3 kullandığınızı öğrenmek için çok fazla çalışma yaparsınız.

Java'yı bu kadar taşınabilir yapan şeylerden biri, işlemcinin bazı özelliklerinin kullanılamamasıdır. Mevcutlarsa onları kullanırdım. Birdenbire, Java kodumun çalışmayacağı CPU'lar var çünkü bu özelliklere sahip değiller. Veritabanı özellikleriyle aynı.

Farkında olmadan bağımsızlığınızı feda etmek kolaydır. SQL verilen bir seçim değil. SQL kullanmaya karar verirseniz, o zaman bir yerde yapın. Yapılmayacak şekilde yapın.

SQL’in güvenlik sorunları olması ve kalıcı bellek modellerine geçmemiz, SQL’in mahkum olduğu anlamına gelmiyor. Sadece bir seçim olduğu noktaya eve götürür. Bu seçimi yapma hakkını korumak istiyorsanız, işi yapmanız gerekir.

80'lerin ve Bob Amca'nın veritabanı hareketinin oldukça kötü bir geçmişe sahip olduğuna dikkat çekmek gerekebilir. Yönetim, bir veritabanı yöneticisini hayatına zorladığında, tüm problemlerini düz bir dosya sistemiyle çözdü. Bu olay onu yıldız danışmanlığı kariyerine itti. (Bu öyküyü ilk temiz kitaplarından birinde anlatır, hangisini unutur) DB'siz sorunları nasıl çözeceğini bilir ve bunları kullanmak gibi davrananlar için çok az sabrı vardır.

Ayrıca, bir müşterinin talep ettiği son dakikaya kadar bir uygulamaya DB eklemeyi bırakmasıyla ilgili bir hikaye anlatır ve isteğe bağlı bir özellik olarak bir günde ekler. Tahminimce, çoğumuzun bağımlılıkları olarak DB kullandığını görüyor. Bize alışkanlığı nasıl tekmeleyeceğimizi göstermeye çalışıyor.

İlk teklifinizden aldığınız teklif (benimki vurgusu),

Çözüm. Tek çözüm. Mı sistemden SQL ortadan tamamen. SQL motoru yoksa, SQLi saldırısı olamaz.

SQL'in yerine ne geçecek? Elbette bir API! Metin dilini kullanan bir API DEĞİL. Bunun yerine, uygun bir veri yapıları kümesi ve işlevi kullanan bir API gerekli verilere erişmek için çağırır.

Rant, uygulama programcılarının SQL kullanmasına izin vermemeye karşıdır.

Önerilen düzeltme, bunun yerine bir API kullanmasına izin vermektir: ki bu SQL değildir ve enjeksiyona izin vermez.

IMO, bu gibi API'lerin örnekleri şunları içerebilir:

• http://bobby-tables.com/csharp , C # programcılarının ADO.NET API'sini kullanabileceğini ileri sürüyor.

  ADO.NET geniş veya derin (yani güçlü veya genel amaçlı) API, çünkü O mükemmel bir örnek değil , aynı zamanda giriş raw (veya çiğ-imsi) SQL için kullanıcılarına sağlar.

• Bazı SQL geliştiricileri veya veritabanı yöneticileri, bir veritabanının (sınırlı sayıda uzmanlıkla yazılmış) saklı yordamlar yoluyla erişime izin verecek şekilde yapılandırılması gerektiğini ve uygulama geliştiricilerin kendi (tehlikeli) SQL sorgularını yazmalarına izin verilmemesi gerektiğini önermektedir.

• "Sistemden SQL'i elimine etmenin" başka bir yolu, veritabanını (SQL'i ortaya çıkaran) başka bir sisteme, bir REST API'si veya benzeri bir şeyle erişmektir.

Bu nedenle, IMO, genel çözüm veya sistem [ler] hala bir veritabanı kullanabilir (özellikle bir veritabanı motorunun faydalı ACID özelliklerini uyguladığı ve iyi ölçeklendirdiği göz önüne alındığında, böyle bir şey yapmadan denemek veya yazmak uygulamaya özgü olanı).

Veritabanının SQL API'si uygulama geliştiricilerden, başka bir API'nin (örneğin, ADO, belki bir ORM, bir Web servisi veya her neyse) arkasına gizlenmişse rant'ın gereksinimleri karşılanır.

Daha genel olarak, uygulamaya özel bir DAL ("veri erişim katmanı" veya "veritabanı soyutlama katmanı") içerdiğini düşünüyorum. Bir DAL, uygulamayı verilerin nasıl ve nerede depolandığı ve / veya alındığı hakkındaki detaylarından izole eder. DAL, bir SQL veritabanı kullanılarak gerçekleştirilebilir veya uygulanmayabilir.

Herkes bu soruyu bir güvenlik bakış açısıyla veya bir SQL mercekle cevaplıyor gibi görünüyor.

Programcılar olarak özel programlarımız için en uygun olan birçok farklı veri yapısını kullandığımızı anlattığı bir Robert Martin dersi gördüm. Bu nedenle, tüm verileri evrensel olarak tablo halinde bir yapıya kaydetmek yerine, verilerimizi karma tablolara, ağaçlara vb. Depolamalıyız. Böylece verileri alabilir ve programa atlayabiliriz.

Onun mesajını sadece bir süredir mevcut depolama konusundaki varsayımlarımızı asırlık SQL tablo formatından başka gelecek olasılıklarını düşünmek için kullanmamız gerektiğini söyleyerek yorumladım. SSD aday bir çözümdür, ancak tek çözüm değildir.

Aslında veritabanlarını ve SQL'i kullanmayacak - açık bir şekilde. İlk referans iyi bilinen bir konudur, ikinci referans bir rant gibi ses çıkarmaktadır. Bununla birlikte, veritabanlarını kullanmak ve SQL kullanmamak için iyi bir neden olduğunu yorumluyorum. Benim açımdan bu makul bir tavsiye bile değil.

Ne yazık ki, kullandığı örnek, daha sonra işaret ettiği iyi bilinen bir çözüme sahip iyi bilinen bir örnek. Genellikle bir programcı ne yaptığını anlamadığında ortaya çıkar. Örneğin, SQL benzeri dizgiler oluşturmak için:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

aksine

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Bu bir DBI perl gibi raylar kodunda yakut için bir örnektir. Sağladığı ray kodu, güvenli ile güvensiz arasında karışmak kolaydır. Pek çok ORM gibi, SQL'in altında ne olduğunu gizler ve bu yüzden sık sık sizin için sql'yi oluşturan ve çalıştıran bir arayüz ile uğraşırsınız. Bu ses neredeyse bir API'nin sizin için ne yapacağını sevmiyor mu?

İlk referansı yorumlamam, iyi bilinen bir çözümü olan iyi bilinen bir konuyu değiştirmemiz gerektiğini önerdiği yönündedir.

Ayrıca, doğru yapılırsa kodun yazılmasını kolaylaştıracağını ve okunabilir hale getireceğini söylemediği için talihsizdir, ancak iyi yapılırsa, yazması daha zor ve daha az okunabilir olabilir. Ek olarak, SQL'in okumasının gerçekten çok kolay olduğu ve genellikle yapmasını beklediğiniz şeyi yaptığı anlamına gelmediğinden bahsetmiyor.

Kısmen doğrudur, sonuçta sonsuz derecede büyük ve hızlı bir belleğe ve sonsuz derecede hızlı bir işlemciye sahip olacağız. Bilgisayarı kısıtlayan mevcut fizikten ayrılıncaya kadar doğru değil.

Evet dönen disk artık geçmişte kaldı ve şimdi SSD kullanıyoruz. Diskler, veri aktarımı başına yaklaşık ~ 10 milisaniye, SSD'ler ~ 0,5 milisaniye (500 mikrosn) veri erişim süresiyle çalışır. RAM, 100 nano saniyelik bir sıradadır, işlemciler 100'lerce pico saniyede çalışır. Veritabanlarına neden ihtiyaç duyduğumuzun kalbi budur. Veritabanları, dönen diskler veya SSD'ler arasındaki ana aktarımlı veri aktarımını yönetir. SSD'lerin ortaya çıkışı veritabanlarına olan ihtiyacı ortadan kaldırmamıştır.

Cevap

sadece insanların SQLi saldırıları nedeniyle SQL / İlişkisel Veritabanlarını kullanmayı bırakmasını mı istiyor?

'Bobby Tables' makalesi, bunun, kendisinin ve SQL'in kullanılmaması için bir neden olduğunu öne sürüyor:

Çözüm. Tek çözüm. SQL sistemden tamamen ortadan kaldırmaktır. SQL motoru yoksa, SQLi saldırısı olamaz.

Başka bir yerde tartışması için başka nedenleri olabilir. Bilmiyorum, çünkü pek fazla bir şey okumam.

konu dışı söz

Bu kısım gerçekten bir cevap değil, fakat SQL değerinin sorusu çok daha ilginç (sanırım diğerleri gibi).

SQL kullanarak çok deneyime sahiptim ve onun güçlü ve zayıf yönlerini tam olarak anladığımı düşünüyorum. Benim kişisel hislerimin aşırı kullanılması ve kötüye kullanılması, ancak onu asla kullanmamamız gerektiği fikrinin saçma olması. 'Her zaman SQL' veya 'SQL asla' seçmemiz gerektiği fikri yanlış bir ikiliktir.

SQL enjeksiyonu, SQL kullanmamak için bir argüman olduğu sürece, gülünç olur. Bu oldukça basit bir çözüm ile iyi anlaşılmış bir sorundur. Bu argümanla ilgili sorun, SQLi'nin var olan tek güvenlik açığı olmamasıdır. JSON API'lerinin kullanılmasının sizi güvence altına aldığını düşünüyorsanız, büyük bir süpriz yapmaktasınız.

Her geliştiricinin "13'üncü Cuma: JSON'a Saldırı - Alvaro Muñoz ve Oleksandr Mirosh - AppSecUSA 2017" başlıklı bu videoyu izlemesi gerektiğini düşünüyorum.

İzleyecek vaktiniz veya eğiminiz yoksa, işte ana fikir: Pek çok JSON seri kaldırma kütüphanesinde uzaktan kod yürütme güvenlik açığı bulunmaktadır. XML kullanıyorsanız, endişelenecek daha çok şey var. SQL'i mimarinizden yasaklamak sisteminizin güvenliğini sağlamaz.

Sadece kısa bir ifadeye değinmek istiyorum:

Yoksa sadece insanların SQLi saldırıları nedeniyle SQL / İlişkisel Veritabanlarını kullanmayı bırakmasını mı istiyor?

Hayır. Bu yanlış bir varsayımdır. Araba kullanmayı bırakmamız gerektiğini söyleyemeyiz, çünkü araba kazalarında ölen insanlardan sorumludurlar. Aynı şekilde, SQL / ilişkisel veritabanları (veya RDBMS gibi bu bağlamdaki herhangi bir şey), bir saldırganın web uygulamanızda gerçekleştirebileceği kötü niyetli SQL yükünden sorumlu değildir. Yazarın bunu kastetmediğinden eminim, çünkü bu amaçla bir SQL enjeksiyon önleme kopya kağıdı var .

Martin'in problemi , doğrudan kullanıcı girdisinden dinamik SQL inşa eden programcıların olduğu gibi gözüküyor (affet beni, öncelikle bir C ve C ++ programcısıyım):

sprintf( query, "select foo from bar where %s;", user_input );

Bu kesinlikle mide ekşimesi için bir reçetedir (bu nedenle Bobby Tables şeridi). Bir üretim sisteminde böyle bir kod koyan herhangi bir programcı paddlin'i hak eder '.

Hazırlanan ifadeleri kullanarak ve girdilerinizi uygun şekilde temizleyerek sorunu hafifletebilir (tamamen ortadan kaldıramazsanız). SQL'i bir API'nin arkasına gizleyebilirsiniz, böylece programcılar doğrudan sorgu dizeleri oluşturmazlar, (Martin'in savunuculuğunun bir parçasıdır) çok daha iyidir.

Fakat tamamen SQL'den kurtulmak için bunun pratik ya da arzu edilebilir olduğunu sanmıyorum. İlişkisel modeller kullanışlıdır , bu yüzden ilk etapta var olurlar ve SQL muhtemelen ilişkisel modellerle çalışmak için en iyi arayüzdür.

Her zaman olduğu gibi, iş için doğru aracı kullanmak meselesi. Alışveriş sepeti uygulamanızın eksiksiz bir ilişkisel modele ihtiyacı yoksa, ilişkisel bir model kullanmayın (yani, SQL kullanmanıza gerek kalmayacak). İlişkisel bir modele ihtiyaç duyduğunuz zamanlarda, o zaman neredeyse kesinlikle SQL ile çalışacaksınız.

Bağladığınız iki kaynak farklı mesajlar iletir:

Blog yazısı, veri erişim mantığının çalışma zamanında metin olarak olmaması gerektiğini, güvenilmeyen kullanıcı girişi ile karıştırılmaması gerektiğini söylüyor. Yani blog yazısı, dizeleri birleştirerek sorgu yazmayı kınadı.

Ders farklı. İlk fark tonda: Ders spekülasyon yapıyor ve soru soruyor, ama kınıyor. Veritabanlarının kötü olduğunu söylemiyor, ancak bir veritabanı olmadan kalıcılığı hayal etmemize meydan okuyor. İlişkisel veritabanlarının yaygınlaşmasından bu yana geçen 30 yıl boyunca birçok şeyin değiştiğini ve ısrarcı teknoloji seçimimizi makul bir şekilde etkileyebilecek iki olayı vurguladığını savunuyor:

• Depolama alanı yaklaşık 1 milyon faktörü artırdı - karşılaştırılabilir fiyatlarla! Sonuç olarak, depolama alanını korumak için daha az, özellikle de silmek artık gerekli değildir. Salt okunur depolama kullanılarak, okuma kilitleri gerekli olmadığından eşzamanlılık denetimi basitleştirilebilir. Bu işlem ihtiyacını ortadan kaldırabilir.
• erişim zamanları düşmüştür, çünkü çoğu veri kümesi artık RAM'e sığmaktadır ve bu da okuma gecikmesini büyük ölçüde azaltmaktadır.

Değişen bu koşullar optimal sebat teknolojisini değiştiriyor mu? İlginçtir ki, Bob Amca söylemez - muhtemelen tüm cevaplar için hiçbir programın doğru olmayacağını düşünüyor. Bu yüzden ısrarlı teknoloji seçimimizi taş tabletler içine almaktan ziyade ayrıntılarıyla ele almamız ve akranlarımıza bilgelik olarak aktarmamızı sağlıyor.

Alternatifler var mı?

Dizgi olmadan veri erişim mantığını yazmak tamamen mümkündür. Java ülkesinde, sorguların veritabanı şemanızdan oluşturulan güvenli bir akıcı API kullanarak tanımlandığı QueryDSL'yi kullanabilirsiniz . Böyle bir sorgu aşağıdaki gibi görünebilir:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Gördüğünüz gibi, sorgu mantığı, sorgunun güvenilir yapısını güvenilmeyen parametrelerden açıkça ayıran bir Dize olarak ifade edilmez (ve tabii ki, QueryDSL parametreleri asla sorgu metnine dahil etmez, ancak sorguyu ayırmak için hazırlanmış ifadeleri kullanır. JDBC seviyesindeki parametreleri için). QueryDSL ile SQL enjeksiyonunu elde etmek için, bir dizgeyi ayrıştırmak ve bir sözdizimi ağacına çevirmek için kendi çözümleyicinizi yazmanız gerekir ve bunu yapsanız bile, muhtemelen kötü şeyler için destek eklemeyeceksiniz select ... into file. Kısacası, QueryDSL, SQL enjeksiyonunu imkansız hale getirir ve ayrıca programcı verimliliğini arttırır ve yeniden yapılandırma güvenliğini arttırır. Çalışan tıkaçlar doğuracak kadar uzun süredir var olan web uygulama güvenliği için en büyük riski önledive geliştirici verimliliğini artırdı? Sorguları hala dizge olarak yazarsanız yanlış yaptığınızı söylemeye cesaret ediyorum.

İlişkisel veri tabanlarına alternatifler söz konusu olduğunda, postgres'in çok versiyonlu eşzamanlılık kontrolünün aynen böyle bir sadece son ek veri yapısının olduğunu düşünüyorum, belki de daha fazla etkinlik mağazalarını ve etkinlik kaynağını düşünüyor olsa da Bob Amca'nın hakkında konuştuğunu bilmek ilginçtir. desen de RAM'de mevcut durumunu tutma kavramı ile güzel uygun genel olarak.