SQL'e (dil) iyi alternatifler nelerdir? [kapalı]

Ara sıra SQL'in ne kadar berbat olduğu ve bunun iyi bir dil olmadığı hakkında şeyler duyuyorum, ancak alternatifleri hakkında pek bir şey duymadım. Öyleyse, aynı amaca (veritabanı erişimi) hizmet eden diğer iyi diller midir ve onları SQL'den daha iyi yapan nedir? Bu alternatif dili kullanan iyi veri tabanları var mı?

DÜZENLEME: SQL'e aşinayım ve her zaman kullanıyorum. Bununla ilgili bir sorunum yok, sadece var olabilecek herhangi bir alternatifle ve insanların neden onları daha çok sevmeleriyle ilgileniyorum.

Ayrıca alternatif veri tabanları (NoSQL hareketi) aramıyorum, sadece veri tabanlarına farklı erişim yolları aramıyorum.

Hem otomatik olarak üretme hem de ayrıştırma açısından SQL'in sözdizimiyle çalışmanın zor olduğuna kesinlikle katılıyorum ve bu, koyduğumuz talepler için SQL tasarlıyor olsaydık bugün yazacağımız dil tarzı değildir. bugün üzerinde. Bugün dili tasarlarsak çok çeşitli anahtar kelimeler bulacağımızı sanmıyorum, birleşim sözdiziminin farklı olacağından şüpheleniyorum GROUP_CONCAT, davranışını kontrol etmek için parantezlerin ortasına daha fazla anahtar kelime yapıştırmak yerine daha normal sözdizimi gibi işlevler ... bugün dili yeniden tasarlarsak düzeltilmesini istediğiniz / beklediğiniz SQL'de kendi tutarsızlıklar ve fazlalıklar listenizi oluşturun.

İlişkisel veritabanlarına (yani bir protokol olarak SQL) konuşmak için SQL'e alternatif yoktur, ancak uygulamalarınızda SQL yazmanın birçok alternatifi vardır. Bu alternatifler, ilişkisel veritabanları ile çalışmak için ön uçlar şeklinde uygulanmıştır. Bazı ön uç örnekleri şunları içerir:

• Lisp mirası nedeniyle muhtemelen en esnek olan SchemeQL ve CLSQL , ancak aynı zamanda diğer ön uçlardan çok daha fazla SQL gibi görünüyorlar.
• LINQ (.Net olarak)
• ScalaQL ve ScalaQuery (Scala'da)
• Ruby'de SqlStatement , ActiveRecord ve diğerleri,
• HaskellDB
• ... liste diğer birçok dil için devam ediyor.

Bence bugün temel temanın, SQL'i yeni bir sorgu diliyle değiştirmek yerine, bunun yerine normal günlük programlama dillerimizde SQL'i gizlemek için dile özgü ön uçlar oluşturuyoruz ve SQL'i ilişkisel ile konuşma protokolü olarak ele alıyoruz. veritabanları.

Bu listeye bir göz atın.

Hazırda Bekletme Sorgu Dili muhtemelen en yaygın olanıdır. Hibernate'in avantajı, nesnelerin ilişkisel veritabanına çok kolay (neredeyse otomatik olarak) eşlenmesi ve geliştiricinin veritabanı tasarımı yapmak için fazla zaman harcamak zorunda olmamasıdır. Check out hazırda web sitesini daha fazla bilgi için. Eminim diğerleri diğer ilginç sorgu dilleriyle uyumludur ...

Elbette, orada pek çok NoSQL içeriği var, ancak bunlarla ilgilenmediğinizi özellikle belirtiyorsunuz.

"Zaman zaman SQL'in ne kadar berbat olduğu hakkında bir şeyler duyuyorum ve bu iyi bir dil değil"

SQL otuz yaşın üzerinde. "Hangi özelliklerin bir şeyi 'iyi' bir dil, hangilerinin onu 'kötü' hale getirdiğine ilişkin içgörüler, SQL'in kendisinden daha hızlı gelişti.

Ayrıca SQL, "ilişkisel olmak için gerekenlerin" mevcut standartlarına uyan bir dil değildir, bu nedenle SQL, önyüklenecek ilişkisel bir dil değildir.

"ama alternatifleri hakkında pek bir şey duymadım."

Sizi yalnızca yanlış yerlerde (yani, yalnızca ticari DBMS endüstrisi) duymaya çalıştığınız ihtimalini düşünmeye davet ediyorum.

"Öyleyse, aynı amaca (veritabanı erişimi) hizmet eden diğer iyi diller midir ve onları SQL'den daha iyi yapan nedir?"

Date & Darwen, modern bir veri işleme dilinin uyması gereken özellikleri, en son versiyonu "Veritabanları, Türler ve İlişkisel Model" kitaplarında açıklanan "Üçüncü Manifesto" da tanımlıyor.

"Bu alternatif dili kullanan iyi veritabanları var mı?"

"İyi" derken "endüstriyel güç" gibi bir şeyi kastediyorsan, hayır. Mevcut en yakın şey muhtemelen Dataphor olacaktır.

Rel projesi, "Veritabanları, Türler ve İlişkisel Model" de tanımlanan Öğretici D dili için bir uygulama sunar, ancak Rel'in mevcut ana hedefi doğası gereği eğitici olmaktır.

SIRA_PRISE projem "gerçekten ilişkisel" veri yönetimi için bir uygulama sunuyor, ancak bunu "bir dilin uygulaması" olarak etiketlemekten de çekiniyorum.

Ve elbette, bazılarının önerdiği gibi ilişkisel olmayan bazı şeylere de bakabilirsiniz, ancak kişisel olarak ilişkisel olmayan veri yönetimini onlarca yıllık teknolojik gerileme olarak görüyorum. Dikkate değer değil, yani.

Oh, bu arada, veritabanlarını yönetmek için kullanılan bir yazılım sistemi "veritabanı" değil, kısaca "Veri Tabanı Yönetim Sistemi", "DBMS" dir. Tıpkı bir fotoğrafın kamera ile aynı şey olmadığı gibi ve kameralardan bahsediyorsanız ve kafa karışıklığını önlemek istiyorsanız, o zaman "fotoğraf" yerine doğru "kameralar" kelimesini kullanmalısınız.

Belki de eleştiriyi düşünüyorsunuz. C. Date ve arkadaşları mevcut ilişkisel veritabanları ve SQL'e karşı söylediler; sistemler ve dilin% 100 ilişkisel olmadığını ve olması gerektiğini söylüyorlar. Burada gerçek bir sorun görmüyorum; Gördüğüm kadarıyla, sadece SQL kullanma şeklinizi disipline ederek,% 100 ilişkisel bir sisteme sahip olabilirsiniz.

Şahsen karşılaşmaya devam ettiğim şey, SQL'in teorik temeli olan ilişkisel cebirden miras aldığı ifade gücünün eksikliği. Bir sorun, tarihlere, zaman damgalarına vb. Göre işaretlenmiş verilerle çalışırken karşılaştığınız etki alanı siparişinin kullanımı için destek eksikliğidir. Bir keresinde, zaman damgalarıyla dolu bir veritabanı üzerinde tamamen düz SQL'de bir raporlama uygulaması yapmayı denedim ve bu mümkün değildi. Bir diğeri, yol geçişi için destek eksikliğidir: verilerimin çoğu, yolları geçmem gereken yönlendirilmiş grafiklere benziyor ve SQL bunu yapamıyor. ("Geçişli kapanıştan" yoksundur. SQL-1999 bunu "özyinelemeli alt sorgularla" yapabilir, ancak bunları henüz gerçek kullanımda görmedim. SQL'in üstesinden gelmek için çeşitli hackler de var ama çirkinler.) Bu sorunlar Bu arada, Date'in bazı yazılarında da tartışıldı.

Son zamanlarda geçişli kapatma sorununu güzel bir şekilde ele alan .QL'e işaret edildim , ancak sorunu sıralı alan adlarıyla çözüp çözemeyeceğini bilmiyorum.

Doğrudan cevap: Orada ciddi bir rakip olduğunu sanmıyorum. DBase ve taklitçileri (Foxpro, Codebase vb.) Bir süredir rakipti, ancak temelde veritabanı sorgu dili savaşını kaybettiler. Progress ve Paradox ve adlarını hatırlamadığım ve kesinlikle daha önce hiç duymadığım birçok başka kullandığım gibi kendi sorgu diline sahip birçok başka veritabanı ürünü var. Ama başka hiçbir rakibin pazardan önemsiz olmayan bir pay almaya yaklaştığını bile sanmıyorum.

Bir veritabanı formatı ile bir sorgu dili arasında bir fark olduğunun basit bir kanıtı olarak, kullandığım son DBase sürümü - yıllar önce - hem "geleneksel" DBase sorgu dilini hem de SQL'i sunuyordu, her ikisi de kullanılabilir. aynı verilere erişmek için.

Side ramble: SQL'in berbat olduğunu söyleyemem ama birçok kusuru var. Yılların getirdiği tecrübe ve şimdi sahip olduğumuz geçmiş görüşlerin faydasıyla, eminim daha iyi bir sorgu dili tasarlayabiliriz. Ancak daha iyi bir sorgulama dili oluşturmak ve insanları onu kullanmaya ikna etmek çok farklı iki şeydir. İnsanları öğrenme zahmetine değdiğine ikna etmek yeterli olur mu? İnsanlar, SQL'i etkili bir şekilde kullanmayı öğrenmek için yaşamlarının uzun yıllarını harcadılar. Yeni dilinizin kullanımı daha kolay olsa bile, kesinlikle bir öğrenme eğrisi olacaktır. Ve mevcut sistemlerinizi SQL'den yeni dile nasıl geçirirsiniz? Vb Elbette, C ++, C # gibi yapılabilir ve Java büyük ölçüde COBOL ve FORTRAN'ı devirmiştir. Ancak bunu başarmak için teknik üstünlük ve iyi pazarlamanın bir kombinasyonu gerekir.

Yine de, birileri onu eleştirdiğinde SQL'i savunmak için acele eden, SQL ile ilgili herhangi bir sorunun SQL'in herhangi bir hatası değil, kullanmamanız gereken bir SQL hatası olmadığında ısrar eden insanlardan kıkırdamalar alıyorum. mükemmelliğini anlamak için gerekli olan şeylerin daha yüksek düzeyine ulaştı. Sakin olun, derin bir nefes alın: Annenize değil, bir bilgisayar diline hakaret ediyoruz.

LINQ to SQL'e bir göz atın ...

Birkaç ay önce denedim ve asla arkana bakmadım ...

1980'lerde ObjectStore şeffaf nesne erişimi sağlıyordu. Tüm bu ekstra sızıntılı soyutlama katmanları dışında, bir RDBMS artı bir ORM gibiydi: nesneleri doğrudan veritabanında depoladı.

Yani bu alternatif gerçekten "hiç dil yok" ya da belki "zaten kullanmakta olduğunuz dil" idi. C ++ kodu yazarsınız ve yerel nesnelermiş gibi nesneler oluşturur veya bunların üzerinden geçersiniz ve veritabanı her şeyi gerektiği gibi hallederdi. ActiveRecord'a benziyor ama aslında ActiveRecord pazarlama saldırılarının iddia ettiği kadar iyi çalıştı. :-)

(Tabii ki, Oracle'ın pazarlama gücüne sahip değildi ve MySQL'in sıfır maliyeti yoktu, bu yüzden herkes onu görmezden geldi. Şimdi bunu RDBMS'ler ve ORM'ler ile kopyalamaya çalışıyoruz ve bazı insanlar bu tabloları gerçekten tartışmaya çalışıyor Nesneleri depolamak için mantıklı ve bilgisayarınıza nesneleri tablolarla nasıl eşleştireceğini anlatmak için dev XML dosyası yazmak bir şekilde makul bir çözümdür.)

Kendi veritabanı sunucusuna (D konuşan) ve kullanıcı arayüzlerini sorgu dilinden türetme becerisine sahip açık kaynaklı bir ilişkisel geliştirme ortamı olan Dataphor'a bakmak ilginizi çekebilir .

Ayrıca, görünen o ki, Ingres hala QUEL'i destekliyor ve açık kaynak.

Bugünlerde genel hareket NoSQL; genellikle bu teknolojiler şunlardır:

• Verileri anahtar / değer çiftleri olarak depolayan dağıtılmış "hashtable'lar"
• Belge odaklı veritabanları

Kişisel olarak, ihtiyaçlarınızı karşıladığı sürece SQL'de yanlış bir şey olmadığını düşünüyorum. SQL anlamlı ve yapılandırılmış verilerle çalışmak için harikadır.

SQL, tasarlandığı etki alanı için - birbiriyle ilişkili veri tabloları için iyi çalışır. Bu genellikle geleneksel ticari veri işlemede bulunur. Karmaşık bir nesne ağını sürdürmeye çalışırken SQL o kadar iyi çalışmaz.

İhtiyaçlarınız nispeten geleneksel verileri depolamak ve işlemekse, bazı SQL tabanlı DBMS kullanın.

Düzenlemenize yanıt olarak:

İlişkisel veri depolarından veri almak için SQL DML'ye alternatifler arıyorsanız, SQL'e ciddi bir alternatif bulamadım.

SQL'in aldığı darbeler, bence, dilin dayandığı temel veri depolama ilkelerinin aksine, dile karşı değildir. İnsanlar genellikle SQL dilini RDBMS'lerin üzerine inşa edildiği ilişkisel veri modeliyle karıştırırlar.

İlişkisel Veritabanları, etraftaki tek veritabanı türü değildir. Başkalarının yanıtlarında görmediğim için Nesne Veritabanları hakkında bir şey söylemeliyim . RDBMS yerine nesnelerin kalıcılığı için ZODB kullanan Zope python çerçevesiyle ilgili bazı deneyimlerim vardı (evet, ZODB'yi zope içinde başka bir veritabanıyla değiştirmek teorik olarak mümkün ama en son kontrol ettiğimde onu çalıştırmayı başaramadım, yani Bu konuda olumlu olmayın).

ZODB zihniyeti gerçekten farklı, daha çok kalıcı olacak nesne programlaması gibi.

ORM bir tür dil olarak görülebilir

Bir bakıma ORM'nin Nesne-veritabanı modeliyle ilgili olduğuna inanıyorum: her zamanki nesne modeliniz aracılığıyla kalıcı verilere erişim. Bu bir tür dil ve biraz pazar payı kazanıyor, ancak şimdilik onu bir dil olarak değil, soyutlama katmanı olarak görüyoruz. Bununla birlikte, bir ORM'yi bir Nesne veritabanı üzerinden kullanmanın SQL'e göre çok daha verimli olacağına inanıyorum (başka bir deyişle, bazı SQL veritabanlarını emilen temel katmanlar olarak kullandığım ORM'lerin performansı).

SQL'in birçok uygulaması vardır (SQL Server, mysql, Oracle, vb.), Ancak ilişkisel veri depolama ve erişim için tasarlanmış genel amaçlı bir dil olma anlamında aynı amaca hizmet eden başka bir dil yoktur .

Orada nesne veritabanları gibi db4o ve benzeri sözde vardır NoSQL sadece herhangi bir veri depolama mekanizması hakkında atıfta veritabanları gelmez gibi açık kaynak ürünler, en çok SQL güveniyor ama Cassandra Google'ın gevşek dayalı Bigtable kavram.

CDF gibi bir dizi özel amaçlı veritabanı ürünleri de vardır, ancak muhtemelen bunlar için endişelenmenize gerek yoktur - eğer ihtiyacınız varsa, bileceksiniz.

Bunların hiçbiri SQL ile eşdeğer değildir.

Bu onların "daha iyi" veya "daha kötü" oldukları anlamına gelmez - sadece aynı değiller. Dennis Forbes, geçtiğimiz günlerde SQL'e karşı ortaya çıkan bir dizi garip iddiayı ortadan kaldıran harika bir yazı yazdı . Bu şikayetlerin büyük ölçüde iş için yanlış aracı seçen veya SQL DBMS'lerini düzgün kullanmayan kişilerden ve dükkanlardan kaynaklandığını iddia ediyor (ve kabul ediyorum) (artık şaşırmıyorum bile. her sütunun birvarchar(50) ve hiçbir yerde tek bir indeks veya anahtarın olmadığı ).

Başka bir sosyal ağ sitesi uyguluyorsanız ve ACID ilkeleriyle çok ilgilenmiyorsanız, kesinlikle db4o gibi ürünleri araştırmaya başlayın. Ancak, kritik bir iş sistemi geliştiriyorsanız , "SQL berbat" korosuna katılmadan önce iki kez düşünmenizi şiddetle tavsiye ederim. Önce araştırmayı yapın, çeşitli ürünlerin hangi özellikleri destekleyip destekleyemeyeceğini öğrenin.

Düzenle - Cevabımı yazmakla meşguldüm ve birkaç dakika içinde soru güncellemesini almadım. Bunu söyledikten sonra, SQL aslında DBMS'nin kendisinden ayrılamaz. Bir SQL veritabanı ürünü çalıştırırsanız, buna SQL, nokta ile erişirsiniz.

Belki sözdizimi üzerinden soyutlamalar arıyorsunuz; Linq to SQL, Entity Framework, Hibernate / NHibernate, SubSonic ve diğer ORM araçlarının tümü, tamamen SQL olmayan kendi SQL benzeri sözdizimini sağlar. Bunların tümü SQL'e "derlenir". SQL Server'ı çalıştırırsanız, veritabanında çalışacak herhangi bir .NET dilinde kod yazmanıza olanak tanıyan CLR Fonksiyonları / Prosedürleri / Tetikleyicileri de yazabilirsiniz; ancak, bu aslında SQL'in yerine geçmez, daha çok onun bir uzantısıdır.

Bir SQL veritabanının üstüne katmanlayabileceğiniz herhangi bir tam "dil" farkında değilim; farklı bir veritabanı ürününe geçmenin dışında, sonunda borudaki SQL'i göreceksiniz.

SQL fiilen geçerlidir.

Geliştiricileri bundan korumaya çalışan çerçeveler, nihayetinde kendi özel dillerini yarattı (Hibernate HQL akla geliyor).

SQL bir sorunu oldukça iyi çözer. Öğrenmek, üst düzey bir programlama dilinden daha zor değildir. Zaten işlevsel bir dil biliyorsanız, SQL'i kavramak çok kolay.

Son teknoloji veritabanları (Oracle ve SQL Server) sağlayan önde gelen veritabanı satıcılarının SQL'i desteklediğini ve optimizasyon motorlarına vb. Yıllarca yatırım yaptığını ve SQL'deki tüm önde gelen veri modelleme yazılımları ve değişiklik yönetimi yazılımı anlaşmalarını göz önünde bulundurursak, en güvenli bahis.

Ayrıca, bir veritabanında sorgulardan daha fazlası vardır. Ölçeklenebilirlik, yedekleme ve kurtarma, veri madenciliği var. Büyük satıcılar, yeni "önbellek" motorlarının bile dikkate almadığı birçok şeyi destekliyor.

SQL ile ilgili sorunlar beni Portland Pattern Repository wiki üzerinden SMEQL adlı bir taslak sorgu dili oluşturmaya motive etti . Yorumlar Hoş Geldiniz. İşlevsel programlamadan ve IBM'in deneysel Business System 12 dilinden fikirler alıyor. (Başlangıçta TQL olarak adlandırdım, ancak daha sonra bu adın alındığını buldum.)

.NET dünyasında, hala SQL-esque hissine sahip olsa da, LINQ-to-SQL, verilerinizin SQL ve bellek içi .NET işlemelerinin iyi bir karışımına sahip olmanızı sağlayacaktır. Ayrıca, kimsenin gerçekten yapmak istemediği alt düzey veri tesisatını da basitleştirir.

Tamamen farklı bir zihniyete sahip bir veritabanı türü görmek istiyorsanız, CouchDB'ye bir göz atın . "Daha iyi" açıkça göreceli bir gerekliliktir ve bu tür ilişkisiz veritabanı "Daha iyi" dir, ancak yalnızca belirli senaryolarda.

Dil SQL çok güçlüdür ve ilişkisel veritabanı yönetim sistemleri büyük bir başarı olmuştur ve hala da öyledir. Ancak, çok yüksek ölçeklenebilirlik ve kullanılabilirlik gerektiren ancak yüksek derecede veri tutarlılığı gerektirmeyen bir uygulama sınıfı vardır (önemli olan nihai tutarlılıktır). Çeşitli sistemler, tam ACID uyumlu işlemlere olan ihtiyacı ortadan kaldırarak RDBMS'den daha iyi performans ve ölçeklendirme elde eder. Bunlara "NoSQL" adı verildi, ancak diğerlerinin de belirttiği gibi, bu yanlış bir isimdir: belki de NoACID veritabanları olarak adlandırılmaları gerekir.

Michael Stonebraker, "NoSQL" Tartışmasının SQL ile İlgisi Yok'ta bunu ele alıyor .