İlişkisel olmayan DB'lerle yeni başladım ve hala kafamı etrafına dolayıp en iyi modelin ne olacağını bulmaya çalışıyorum. Ve sadece CouchDB adına konuşabiliyorum.
Yine de bazı ön sonuçlara sahibim:
İlişkisel olmayan dünyada çok daha iyi çalışan alternatif tasarımlar buldunuz mu?
Tasarım odağı değişir: Belge modelinin tasarımı (DB tablolarına karşılık gelir) neredeyse önemsiz hale gelirken, her şey görünümlerin tasarlanmasına bağlıdır (sorgulara karşılık gelir).
Belge DB'si karmaşıklıkları değiştirir: SQL esnek olmayan verilere ve esnek sorgulara sahiptir, belge DB'leri bunun tam tersidir.
CouchDB modeli "JSON belgeleri" koleksiyonudur (temelde iç içe geçmiş karma tablolar). Her belgenin benzersiz bir kimliği vardır ve kimlik ile önemsiz bir şekilde alınabilir. Diğer herhangi bir sorgu için, eşleme / azaltma işlevlerinin adlandırılmış kümeleri olan "görünümler" yazarsınız. Görünümler, anahtar / değer çiftlerinin bir listesi olarak bir sonuç kümesi döndürür.
İşin püf noktası, bir SQL veritabanını sorguladığınız anlamda veritabanını sorgulamamanızdır: Görünüm işlevlerini çalıştırmanın sonuçları bir dizinde saklanır ve yalnızca dizin sorgulanabilir. ("Her şeyi al", "anahtarı al" veya "anahtar aralığını al" gibi.)
SQL dünyasındaki en yakın benzetme, yalnızca saklı yordamları kullanarak DB'yi sorgulayabilmenizdir - desteklemek istediğiniz her sorgu önceden tanımlanmış olmalıdır.
Belgelerin tasarımı son derece esnektir. Yalnızca iki kısıt buldum:
- Bir birleştirmeye karşılık gelen hiçbir şey olmadığından, ilgili verileri aynı belgede bir arada tutun.
- Her belge güncellemesi bir yeniden endekslemeyi tetiklediğinden, belgeleri çok sık güncellenecek kadar büyük yapmayın (yıl için tüm şirket satışlarını aynı belgeye koymak gibi).
Ancak her şey görünümlerin tasarlanmasına bağlıdır.
Bulduğum alternatif tasarımlar, CouchDB ile herhangi bir SQL veritabanından daha büyük iş emirlerinin depolama seviyesinden çok sistem seviyesinde olduğunu buldum. Bazı verileriniz varsa ve bunları bir web sayfasına sunmak istiyorsanız, toplam sistemin karmaşıklığı en az% 50 oranında azaltılır:
- DB tabloları tasarlamak yok (küçük sorun)
- ODBC / JDBC ara katmanı yok, http üzerinden tüm sorgular ve işlemler (orta düzey sorun)
- JSON'dan basit DB'den nesneye eşleme, SQL'de aynı olanla karşılaştırıldığında neredeyse önemsiz (önemli!)
- Belgelerinizi AJAX kullanarak tarayıcı tarafından doğrudan alınacak şekilde tasarlayabileceğiniz ve HTML olarak görüntülenmeden önce biraz JavaScript parlatma ekleyebileceğiniz için, potansiyel olarak tüm uygulama sunucusunu atlayabilirsiniz. (KOCAMAN!!)
Normal web uygulamaları için, belge / JSON tabanlı DB'ler büyük bir kazançtır ve daha az esnek sorguların ve veri doğrulama için bazı ekstra kodların dezavantajları, ödenmesi gereken küçük bir bedel gibi görünmektedir.
İmkansız görünen herhangi bir şeye başınızı vurdunuz mu?
Henüz değil. Bir veritabanını sorgulamanın bir yolu olarak eşleme / küçültme alışılmadık bir şeydir ve SQL yazmaktan çok daha fazla düşünmeyi gerektirir. Oldukça az sayıda ilkel vardır, bu nedenle ihtiyacınız olan sonuçları elde etmek, öncelikle anahtarları nasıl belirleyeceğiniz konusunda yaratıcı olmaktır.
Sorguların aynı anda iki veya daha fazla belgeye bakamaması konusunda bir sınırlama vardır - hiçbir birleştirme veya diğer türden çoklu belge ilişkileri, ancak şimdiye kadar hiçbir şey aşılamaz olmamıştır.
Örnek bir sınırlama olarak, sayımlar ve toplamlar kolaydır, ancak ortalamalar bir CouchDB görünümü / sorgusu ile hesaplanamaz. Düzeltme: Toplamı döndür ve ayrı ayrı say ve istemcinin ortalamasını hesapla.
Boşluğu herhangi bir tasarım modeliyle doldurdunuz mu, örneğin birinden diğerine çevirmek için?
Bunun mümkün olduğundan emin değilim. Daha çok, işlevsel bir stil programını nesne yönelimli bir stile çevirmek gibi tam bir yeniden tasarım. Genel olarak, SQL tablolarından çok daha az belge türü ve her belgede daha fazla veri vardır.
Bunu düşünmenin bir yolu, ekler ve genel sorgular için SQL'inize bakmaktır: Örneğin, bir müşteri sipariş verdiğinde hangi tablolar ve sütunlar güncellenir? Ve aylık satış raporları için hangileri? Bu bilgi muhtemelen aynı belgede yer almalıdır.
Yani: Müşteri kimliğini ve ürün kimliklerini içeren ve sorguları basitleştirmek için gereken çoğaltılmış alanlara sahip bir Sipariş belgesi. Bir belgedeki herhangi bir şey kolayca sorgulanabilir, örneğin Sipariş ve Müşteri arasında çapraz referans gerektiren her şey müşteri tarafından yapılmalıdır. Dolayısıyla, bölgeye göre satış raporu istiyorsanız, muhtemelen siparişe bir bölge kodu eklemelisiniz.
Şu anda açık veri modelleri yapıyor musunuz (örneğin UML'de)?
Maalesef, belge DB'lerinden önce hiç UML de yapmadım :)
Ama hangi alanların hangi belgelere ait olduğunu ve ne tür değerler içerdiğini söyleyen bir çeşit modele ihtiyacınız var. Hem daha sonra kendi referansınız için hem de DB'yi kullanan herkesin kuralları bildiğinden emin olmak için. Örneğin, bir metin alanında bir tarih depolarsanız artık bir hata almadığınızdan ve herkes istediği herhangi bir alanı ekleyip kaldırabileceğinden, boşluğu almak için hem doğrulama koduna hem de kurallara ihtiyacınız vardır. Özellikle dış kaynaklarla çalışıyorsanız.
RDBMS'lerin sağladığı önemli ekstra hizmetlerden herhangi birini özlüyor musunuz?
Hayır! Ama benim geçmişim web uygulaması geliştiricisi, veri tabanlarıyla sadece yapmamız gereken ölçüde ilgileniyoruz :)
Eskiden çalıştığım bir şirket, birden çok tedarikçinin SQL veritabanlarında çalışmak üzere tasarlanmış bir ürün (web uygulaması) yaptı ve "ekstra hizmetler" DB'den DB'ye o kadar farklı ki her DB için ayrı ayrı uygulanmaları gerekiyordu. Bu nedenle, işlevselliği RDBMS'den çıkarmak bizim için daha az işti. Bu, tam metin aramaya kadar genişledi.
Yani vazgeçiyorsam, ilk etapta asla sahip olmadığım bir şey. Açıkçası, deneyiminiz farklı olabilir.
Bir uyarı: Şu anda üzerinde çalıştığım şey, finansal veriler, hisse senedi fiyatları ve benzerleri için bir web uygulaması. Bu, bir belge DB'si için çok iyi bir eşleşme, benim bakış açıma göre bir DB'nin tüm avantajlarından (kalıcılık ve sorgular) herhangi bir güçlük çekmeden yararlanıyorum.
Ancak bu veriler birbirinden oldukça bağımsızdır, karmaşık ilişkisel sorgular yoktur. En son teklifleri kayan yazıya göre alın, hisse senedi ve tarih aralığına göre fiyat teklifleri alın, şirket meta bilgilerini alın, hepsi bu. Gördüğüm başka bir örnek de bir blog uygulamasıydı ve bloglar da çok karmaşık veritabanı şemaları ile karakterize edilmiyor.
Söylemeye çalıştığım şey, tanıdığım belge DB'lerinin tüm başarılı uygulamalarının, ilk etapta çok fazla ilişkisi olmayan verilerle yapıldığıydı: Belgeler (Google aramasında olduğu gibi), blog gönderileri, haber makaleleri, finansal veriler .
Belge modeline göre SQL ile daha iyi eşleşen veri kümeleri olmasını bekliyorum, bu yüzden SQL'in hayatta kalacağını düşünüyorum.
Ancak, verileri depolamanın ve almanın basit bir yolunu arayan bizler için - ve çoğumuzdan şüpheleniyorum - belge veritabanları (CouchDB'de olduğu gibi) bir nimettir.