Programlama ve veritabanı sorgusunu birleştirme [kapalı]


11

C ++ veya Java gibi nesneye yönelik programlama dilleri için ortak bir öğretici düşünün: hesapları, siparişleri, öğeleri vb. (Veya daha fazla veya daha az eşdeğer bir şeyi) temsil eden nesnelerle basit bir sipariş işleme sistemi oluşturun. Mükemmel sezgisel bir anlam ifade eder, ancak yemek masasındaki fil bunun gerçek olmadığıdır çünkü bunlar hafıza içi nesnelerdir; gerçek bir sistemde, hesaplar, siparişler vb. aslında bellekte ilk başta yaşamazlar, bir veritabanında yaşarlar, bellek temsili sadece kısa ömürlü bir aynasıdır.

Veritabanından okumak ve yazmak için kendinize çok fazla kod yazabilirsiniz, ancak bu çok sıkıcı ve hataya meyillidir, aslında kimse bunu yapmaz.

Herkes bir ORM kullanıyor, ancak bunlar kendi başlarına o kadar sorunlu ki, ünlü bir gazete onlara 'endüstrimizin Vietnam'ı' diyor.

Bu , programlama dili ve veritabanı birbirleri hakkında bilmeyen ayrı şeyler olmak arasındaki bir uyumsuzluk kadar nesne ve ilişkisel bir uyumsuzluk olduğunu sanmıyorum . Konjektif: çözüm, programlama ve veritabanı sorgu dili olan tek bir dile sahip olmaktır, bu da dil çalışma zamanının da veritabanı olmasını ve JIT derleyicisinin de sorgu optimize edici olmasını gerektirir.

Gördüğüm sorunların özeti bu. Sorum şu ki, henüz biri var mı,

  1. Aslında böyle birleşik bir sistem kurdu

  2. Denendi, ancak böyle birleşik bir sistem inşa edemedi

  3. Nasıl inşa edeceğiniz veya neden veya neden olmasın konusunda önemli bir şey yazdı

  4. Sorunu çözmek için alternatif bir yol mu buldunuz?


5
Veritabanı ve kodu birleştiren bir dile sahip olduğunuzda, veritabanı, kod ve HTML'yi birleştiren bir dil bulmanız gerekir. O zaman JSON ile birleşmeniz gerekir. O zaman regexp ile perl'den daha samimi bir şekilde birleşmeniz gerekir. Sonra LDAP gibi hiyerarşik veritabanı ile birleştirmeniz gerekir (örn. Microsoft Active dizini, evet, bu bir veritabanı). O zaman Mongo veya Cassandra gibi anahtar / değer veritabanlarıyla birleşmeniz gerekir. Sonra 3D render vb.
İle

1
Önerilen çözüm uygulamalarınız uzak bir veritabanına erişemeyebilir veya sizi yanlış mı anladım? Çünkü hem uygulama hem de veritabanı çalışma zamanının aynı örneğini kullanır.
Monica

2
Bu teknoloji ile ilgisi yok, veri seti ile ilgisi var. Bir kez kod regex yürütmek için 3 dakika sürüyordu çünkü optimize etmek zorunda kaldım. İnsanların e-postaya yanıt verirken tüm iletileri alıntıladıkları ve e-postaların bazen 5mb'ye çıkabileceği ortaya çıktı. SADECE 5mb regex boğulma olabilir. SQL yeterince hızlıdır.
Regexp'i

2
Ayrıca, "optimize" etmenin ne anlama geldiğinin, uygulamanızın hedeflerine bağlı olarak bir RDBMS içinde bile farklı olduğunu belirtmek gerekir. Neyi endekslersin? Ne zaman? Nasıl? Dizine hangi alanları ekliyorsunuz? Yüksek yazma hızı veya yüksek sorgu hızı için optimize ediyor musunuz veya işlem bütünlüğünü en üst düzeye çıkarıyor musunuz? Bu ticaret, ana dilin bir parçası haline getirilerek değişmez, daha karmaşık bir şey olursa ve geliştiricinin kalıcılık katmanı hakkında şu andan çok daha fazla anlamasını sağlarsa (bir ekibiniz olduğunu varsayarsak, sadece bir kişi)
Paul

1
Ben söz düşünüyorum LINQ burada çok az 1'e ilişkin altındadır
Casey Kuball

Yanıtlar:


7

Bu benim görüşüm. Nereden geldiğini görürsem de, tasarım açısından olduğunu göremiyorum.

Veri kalıcılığı son derece karmaşık bir konudur. Programlama dilleri de öyle. İkisini birleştirmek karmaşıklık patlamasına neden olur. Her ikisini de insanların gerçekten kullanmak isteyebileceği kadar iyi hale getirmek çok çaba gerektirir. Zaten bahsedilen MUMPS'un iyi bir örnek olduğunu düşünüyorum . Ya da tam dil üzerine cıvatalı çeşitli SQL varyantlarına bakabilirsiniz. Kullanılabilir olabilirler, ancak insanların bunları isteyerek kullanacaklarını sanmıyorum.

Bu yüzden onları ayırmak, bu karmaşıklığın nasıl çözüleceğinin açık bir yoludur. Ayrıca, onları birbirine bağlamamakla, zamanla hem değiştirilmesine hem de gelişmesine izin verir. Örneğin, SQL eskidir ve oluşturulduğundan beri fazla değişmemiştir. Ancak uygulamaları çalıştırmak için kullanılan diller aynı dönemde büyük ölçüde değişti. Ve şimdi, tam tersi oluyor. Veritabanları değiştirilirken ve geliştirilirken diller çoğunlukla aynı kalır.

Çalışma zamanı dağıtımı başka bir sorundur. İkisini birleştirmek, hem veritabanı hem de uygulamanın veya web sunucusunun aynı işlemde çalışması gerektiği anlamına gelir. Bu, hem bakım açısından hem de bunları ayrı bilgisayarlarda veya birebir ilişkilerde çalıştırabilme yeteneğinden son derece sınırlayıcıdır.

İkisini aralarında açık API ile ayrı modüllere bölmek, karmaşıklığı düşük tutmanın ve hangi teknolojileri kullanmak istediğiniz ve son parçaların nasıl dağıtıldığı konusunda size esneklik sağlamanın en iyi yoludur.


TL; DR "Bunları birleştirmek endişelerin ayrılmasını ihlal ettiği için iyi bir fikir değil"
ferit

5

Görünüşe göre bazı önemli varsayımlar yapıyorsunuz. Örneğin, herkesin ilişkisel veritabanlarına yazdığını varsayıyorsunuz. Bu sadece durum böyle değil, tüm kodu yazmak ve kalıcılığı yönetmek için yerel bir programlama dili kullanan diğer tatların veritabanlarına (nesne dbs, belge dbs, vb.) Çok sayıda örnek var.

Örneğin, Db4O hem Java hem de C #, Java'da ObjectDB, çeşitli dillerde VelocityDB ile uyumludur. MongoDB'nin sürücüleri, yerel programlama dilinizde bir şeyler yazmanızı sağlar (JavaScript kullanıyorsanız bonus, çünkü kabuğun da aynı sözdizimini kullandığı anlamına gelir).

Çeşitli yerlerde hangi DB motorlarının hangi bağlamlarda daha iyi olduğu ve neden bu cevabın kapsamı için bu alanda kapalı bir soru eklemek için çok fazla tartışma var. Sonuç olarak, her biri farklı şeyler için optimize edilmişlerdir ve yakın zamana kadar SQL, iş uygulamaları için bir tür 'en düşük ortak payda' olarak kabul edildi, çünkü ACID ve performans açısından çok fazla ücretsiz alıyorsunuz (her ikisi de değişiyor olsa da) Son zamanlarda mimariler ve gereksinimler değiştikçe).

Ayrıca, daha önce bir çok "hepsi bir arada" yaklaşımı olduğunu belirtmek gerekir. Ana bilgisayar dillerinde genellikle kendi kalıcılık mantığı vardır ve Smalltalk gibi kod ve veriler arasında hiçbir ayrım yapmayan diller vardır. Yine, bazı kullanım durumları için genellikle iyidir, ancak hepsi için değildir.


5
  1. Evet (ben değil). Buna MUMPS deniyordu .

  2. Buna göre bu eski SE.SE soruya , ya bu makalede , kabakulak çok iyi tasarlanmamıştır. Ama gerçekten sağlık endüstrisinde kullanıldı (ve sanırım bunu kullanan mevcut sistemler var), bu yüzden tam bir başarısızlık değil.

  3. Ne arayacağınızı bildiğiniz için artık bu konuda bilgi bulacaksınız. Yukarıdaki Wikipedia bağlantısıyla başlayın.

  4. Nesneye Dayalı veritabanlarını arayın, birçoğu dile özgüdür. Nesne-ilişkisel uyumsuzluğu ORM'lerden daha basit yollarla ele almaya çalıştılar.


8
Kabakulak cinsinden veritabanı erişimi .... SK = 0 FSK = $ O (^ VA (200, K)) S: 'KW $ P (^ VA (200, K, 0), U, 1) ,! iyi bilinen kabakulak sisteminden hasta isimlerini yazdırır. Sorun çözüldü? Çok değil.
joshp

MUMPS tarafından küfür eden bir meslektaşım var. Daha sonraki sürümlerinde (Cache) daha yakın sözdizimi vardı.
Alexey

2
@Alexey: MUMP'lar hakkında çok şey bilmiyorum, ancak sözdiziminden daha büyük sorunlar, daha büyük programların gelişimini ve bakımını kabus haline getiren hataya açık kapsam belirleme kurallarından daha büyük sorunlar gibi görünüyor.
Doc Brown

@DocBrown İşte tam olarak var. Kapsam belirleme kuralları biraz montaj dili gibidir. Kabakulakların genellikle nasıl yazıldığına dair çok fazla sorun var, sadece OP'nin sorusundan rahatsız oluyor.
joshp

5

Gerçekten de veritabanı ve programlama dilini tek bir ortamda birleştiren çok sayıda sistem vardır.

Smalltalk muhtemelen tanımladığınız şeye en yakın olanıdır. Bellekteki nesne bir "görüntü" içinde kalıcıdır, böylece dil ortamı kutunun dışında bir (nesne) veritabanı kullanılabilir. Ve çoğu modern dil, dil ortamındaki nesnelerin dilin kendisi kullanılarak kalıcı ve sorgulanabileceği anlamına gelen bir çeşit yerleşik kalıcı mekanizmaya sahiptir.

Bu, tek kullanıcılı uygulamalar için çok uygundur. Ancak yaklaşım birden fazla kullanıcıya ölçeklenmeyecektir, çünkü aynı bellek alanını paylaşmaya ihtiyaç duyacaklardır, bu da açıkça kullanıcı miktarına bir sınır koymaktadır. Ölçeklenebilir bir çözüm, eşzamanlılığı yöneten ayrı bir veritabanı sunucusu gerektirir. O zaman bile, belirli bir dil ortamıyla bütünleşen ve dilin kendisindeki nesneleri sürdürmenize ve sorgulamanıza izin veren birden fazla NoSql veritabanı vardır.

Şeylerin ilişkisel yönünden, SQL'in bir üst kümesi olan tam teşekküllü bir programlama dili olan T-SQL gibi dillerimiz var, bu nedenle sorgulama ve DML, keyfi karmaşık prosedürel mantık ile karıştırılabilir. Karmaşık iş uygulaması T-SQL kullanılarak inşa edilmiştir, bu yüzden bu kesinlikle yapılabilir, ancak mevcut eğilim, prosedürel iş mantığını veritabanından uzak tutmaktır.

Bu durumlarda, veritabanının programlama diliyle bütünleştirilmesi ve "empedans uyumsuzluğundan" kaçınması gerçekten çok şık ve kullanışlıdır. Peki neden insanlar hala ilişkisel veritabanlarını programlama ortamından ayrı kullanıyorlar ve bazı ORM-çamurlarıyla köprü kurmaya çalışıyorlar?

Belirli bir programlama dilinden ve ortamından ayrı olarak veriye ve sorgulamaya sahip olmanın birçok avantajı olduğu ortaya çıkıyor.

  • Veri bağımsızlığı. Çoğu kuruluşta verilere aslında birden fazla uygulama tarafından erişilir. Bir mağazanın web kullanıcı arabirimi, bir müşteri destek aracı, bir raporlama motoru vb. Tarafından kullanılan bir veritabanı olabilir. Verilerin kendisi genellikle uzun ömürlüdür, uygulamalar gelir ve gider. Verilerin belirli bir programlama ortamına bağlanması, belirli bir programlama ortamına kilitlenir. Ancak veri sonsuza dek yaşarken programlama dilleri gelir ve gider.
  • Özel sorgulama. Bir veritabanı istemi açmak ve bir sorgu yazmak son derece uygundur. Sorgulama programlama ortamına sıkıca bağlı olsaydı, bu bir programlama görevi olurdu ve sadece geliştiriciler bunu yapabilirdi.
  • Kilitlenmekten kaçının. SQL bir standart olduğu için, birden çok tedarikçi az ya da çok değiştirilebilir veritabanı yönetim sistemleri sağlayabilir. Bu, satıcı kilitlenmesini önler ve ürünleri karşılaştırmayı kolaylaştırır.
  • Gevşek bağlantı. Uygulama katmanı ve veritabanı arasında iyi tanımlanmış bir arayüze sahip olmak, veritabanını uygulama mantığından bağımsız olarak ayarlamayı ve optimize etmeyi mümkün kılar.
  • Paylaşılan arayüz. Veritabanı arayüzü uygulama mantığından bağımsız olduğu için, hazır araçlar profil oluşturma, çoğaltma, analiz ve benzeri işlemler için kullanılabilir.

2

Kafamda birçok kez işlediğim oldukça iyi bir soru. Sorununuzu çözen mevcut bir çözümün bir örneği, tüm web sayfalarını oluşturabilen denetleyiciler yazmak için JavaScript (dahili motorda çalışan) kullandığınız bir ArangoDB grafik veritabanıdır. Veriler, JSON kullanılarak depoya / depodan aktarılır, böylece JavaScript'te yerel olarak erişilebilir ve sorgular gömülü sorgu dilinde yapılır. Bu durumda, veritabanında çalıştırılacak JavaScript'in genişletilmesine bir örnek.

Uygulamada, bu tür kontrolörler, veritabanı yapılandırmasındaki bir kusurdan dolayı güvenlik nedenleriyle halka maruz kalmamalıdır; aksi takdirde bir hata, değerli verilerinizi halka açığa çıkarır.

Kişisel görüşüme göre bu iyi bir yaklaşımdır ve veritabanının toplu veri / metin dizinlerini ve diğer sık ​​sorulan verileri gerçek zamanlı olarak güncelleyecek bir tür harita / azaltma özelliğini destekleyip desteklemediğini göz önünde bulundurarak (ara yük yükleyin) dengeleyici) dağıtılmış bir veritabanında çalışan işlevsel bir uygulama yapar.


1
  1. Aslında böyle birleşik bir sistem kurdu

Evet, bunu Sciter'de yaptım .

Sciter'in betiği yerleşik kalıcılığı olan bir " JavaScript ++ " dır :

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

ndb.rootJS cinsinden normal nesne nerede . Tüm özellikleri ve ondan erişilebilen alt nesneler, kod için şeffaf bir şekilde, gerektiğinde DB'de saklanır ve getirilir:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Veriler DB'de GC döngüsünde, yeterli bellek olmadığında veya açık ndb.commit()çağrıda depolanır .

Storagesınıfa benzersiz / benzersiz olmayan tuşlarla Indexsınıftan vazgeçilebilir sıralı nesne koleksiyonları eşlik eder .

Özellik kümesi MongoDB veya diğer NoSQL veritabanlarına benzer, ancak kimlik ayrı ORM gerektirmez - db erişimi tamamen script araçlarıyla yapılır.


0

Kesinlikle bunun içindeyim ve nereden başlayacağımı bilmiyorum. SQL parlak olabilir ve tüm bu güce ve işlem garantilerine çok amaçlı programlama dilinizde (dizeler koleksiyonu olarak kullanmak veya tanrı yasaklı, bir ORM kullanmak yerine) çok iyi olacağını hayal ediyorum.

Fikrinize yaklaşan tek sisteme aquameta denir (etiket satırı: "PostgreSQL'de yerleşik web dev yığını"; bkz. Https://github.com/aquametalabs/aquameta , http://aquameta.org ). Fikrin kendisinden biraz daha az çılgın olmayan bazı tanıtım videoları vardır (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), ve deli dediğimde, Postgres içinde kendi editörlerini ve kendi sürüm kontrol sistemlerini uyguladıklarını kastediyorum.


0

Bence bu, Microsoft'un LINQ'yu icat etmesinin tam mantığıydı. Birkaç yıldır tam ölçekli üretimde kullanıldığından, bununla ilgili literatür ve hem olumlu hem de olumsuz gerçek dünya deneyimlerinden yansımalar bulmak kolaydır. (Çoğu .net geliştirme mağazası onu kucaklar.)

Linq'de iyi bir başlangıç ​​noktası: https://docs.microsoft.com/en-us/dotnet/csharp/linq/



Linq-to-SQL bir ORM'nin bir bileşenidir ve bu OP'nin özel olarak sorduğu şey değildir.
JacquesB

Linq-sql demedim. Yalnızca programlama dilinin içine yerleştirilmiş, arkasındaki veri deposunun arkasından agnostik olan linq'in kendisinden bahsediyordum.
Clay Fowler
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.