SORU
7 EKİM 2009, ÇARŞAMBA


Modelleme ilkeleri Belgeler CouchDB

Bir süredir cevap vermeye çalıştığım bir soru var ama rakam değil

Nasıl tasarım ya, CouchDB belgeleri bölmek nasıl?

Örneğin bir Blog yazısı.

Yarı" bunu yapmak için, birkaç nesneleri oluşturmak olacaktır: . "ilişkisel

  • Post
  • Kullanıcı
  • Yorum
  • Etiket
  • Parçacık

Bu anlamda büyük bir anlaşma yapar. Ama couchdb (harika tüm sebeplerden dolayı) aynı şeyi modellemek için kullanmaya çalışıyorum ve çok zor oldu.

Orada blog mesajların çoğu bunu nasıl kolay bir örnek ver. Onlar temelde aynı şekilde bölmek, ama 'keyfi' kesinlikle güzel olan her belge için özellikler. ekleyebilirsiniz demek CouchDB böyle bir şey var mı diye:

  • Post (etiketleri ve "sözde" doktor modeller) . parçacıkları
  • Yorum
  • Kullanıcı

Bazı insanlar bile bu size lazım olur diye orada Yorum ve Kullanıcı atmak, derdi:


post {
    id: 123412804910820
    title: "My Post"
    body: "Lots of Content"
    html: "<p>Lots of Content</p>"
    author: {
        name: "Lance"
        age: "23"
    }
    tags: ["sample", "post"]
    comments {
        comment {
            id: 93930414809
            body: "Interesting Post"
        } 
        comment {
            id: 19018301989
            body: "I agree"
        }
    }
}

Çok güzel görünüyor ve anlamak kolaydır. Ben de tüm Yazılan belgelerden sadece yorumlardan çıkarılan görüşlerini yazan, Yorum modeller için, Kullanıcılar ve Etiketleri ile aynı nasıl yapabildiğini.

Ama sonra düşünüyorum, "neden sadece tek bir belge içinde tüm site koymuyoruz?":


site {
    domain: "www.blog.com"
    owner: "me"
    pages {
        page {
            title: "Blog"
            posts {
                post {
                    id: 123412804910820
                    title: "My Post"
                    body: "Lots of Content"
                    html: "<p>Lots of Content</p>"
                    author: {
                        name: "Lance"
                        age: "23"
                    }
                    tags: ["sample", "post"]
                    comments {
                        comment {
                            id: 93930414809
                            body: "Interesting Post"
                        } 
                        comment {
                            id: 19018301989
                            body: "I agree"
                        }
                    }
                }
                post {
                    id: 18091890192984
                    title: "Second Post"
                    ...
                }
            }
        }
    }
}

Kolay olan ne istediğini bulmak için görüş yapabilir.

O zaman sorum şu, ne kadar küçük belgelere belge bölmek, ya da yapmak için zaman karar verirsin "İLİŞKİLER" arasındaki belgeler?

Çok daha fazla olacağını düşünüyorum "Nesne Yönelimli" eğer bölünmüş olsaydı, ve Değeri eşleştirmek için daha kolay Nesneler, yani:


posts {
    post {
        id: 123412804910820
        title: "My Post"
        body: "Lots of Content"
        html: "<p>Lots of Content</p>"
        author_id: "Lance1231"
        tags: ["sample", "post"]
    }
}
authors {
    author {
        id: "Lance1231"
        name: "Lance"
        age: "23"
    }
}
comments {
    comment {
        id: "comment1"
        body: "Interesting Post"
        post_id: 123412804910820
    } 
    comment {
        id: "comment2"
        body: "I agree"
        post_id: 123412804910820
    }
}

... ama sonra daha İlişkisel bir Veritabanı gibi görünmeye başlıyor. Ve genellikle gibi görünen bir şey bana miras times "bütün-site-içinde-bir belge daha zor ilişkileri ile modeli.",

Vs Belge Veritabanları İlişkisel Veritabanları hakkında çok şey okudum, o ana konumuz bu değil. Prensip/CouchDB veri modelleme uygulamak için iyi bir kural ne fazla sadece merak ediyorum.

Başka bir örnek XML dosyaları/veri ile. Bazı XML veri yerleştirme 10 seviyeleri derin ve isterim görselleştirmek kullanarak aynı istemci (Ajax üzerinde Raylar mesela, ya da Flex) isterdim hale JSON dan ActiveRecord, CouchRest, ya da başka herhangi bir Nesne İlişkisel Eşleyici. Bazen ben büyük XML dosyalarını, tüm site yapısı gibi aşağıda ve ben gerek eşleştirmek için Değer Nesneler için kullanılan Raylar app benim öyle bir zorunluluğum yok yazmak başka bir şekilde seri hale getirilirken/kaldırmada veri:


<pages>
    <page>
        <subPages>
            <subPage>
                <images>
                    <image>
                        <url/>
                    </image>
                </images>
            </subPage>
        </subPages>
    </page>
</pages>

Genel CouchDB o zaman sorular şöyle:

  1. /İlke belgeleri (ilişkiler, vb.) bölmek için kullanmak kurallar ne?
  2. Bir belgeye tüm siteye koymak için sorun olur mu?
  3. Eğer öyleyse, nasıl keyfi derinliklerinde düzeyleri ile seri hale getirilirken/kaldırmada belgeler (yukarıda büyük örnek json veya xml gibi) ne yapmalıyım?
  4. Yoksa sadece karar mı VOs bunları açmak musun "bunlar Nesne-İlişkisel Eşleme çok iç içe, sadece onları XML/JSON ham yöntemleri kullanarak erişimi ederim"?

Sorunu söylemek benim için zor oldu yardımın için çok "bu artık nasıl yapmam gerektiğini. teşekkürler Yakında umarım.

Projeler/aşağıdaki siteleri inceledim.

  1. Hierarchical Data in CouchDB
  2. CouchDB Wiki
  3. Sofa - CouchDB App
  4. CouchDB The Definitive Guide
  5. PeepCode CouchDB Screencast
  6. CouchRest
  7. CouchDB README

...ama hala bu soruya cevap vermedin.

CEVAP
30 EYLÜL 2011, Cuma


Bu harika cevaplar zaten var, ama orijinal durum viatropos tarafından açıklanan ile çalışmak için seçenekler karıştırmak için yeni bir CouchDB özellikler eklemek istedim.

Hangi belgeleri bölmek için anahtar nokta çatışmalar daha önce de belirttiğimiz gibi) olabilir. Asla tutmak kitlesel "karışık" belgeler birlikte tek bir belge olarak bir tek düzeltme yolu tamamen ilgisiz güncellemeleri (yorum ekleme ayrıca bir revizyon için tüm site belge örneği). Çeşitli küçük belgeleri arasındaki ilişkileri veya bağlantıları yönetme ilk başta kafa karıştırıcı olabilir, ama CouchDB tek tepkileri farklı parçaları birleştirmek için birkaç seçenek sunar.

İlk büyük bir görünüm harmanlama. Sorgu azaltmak/harita sonuçlarını içine anahtar/değer çiftleri olduğunda, yayma, anahtarları sınıflandırılmaktadır UTF-8 tabanlı harmanlama (""önce "b"). gelir Ayrıca haritadan karmaşık tuşları çıktı/dizilerindeki gibi azaltabilirsiniz: ["a", "b", "c"]. Eklemek için izin verecek bunu bir "ağaç" her türlü dizi anahtarları ile inşa. Yukarıdaki örneği kullanarak, çıkış elimizden post_id, tür şeyleri daha sonra KİMLİĞİNİ sonra (gerekirse) kontrollerini yapıyoruz. Biz o zaman kullanabiliriz döndürülen değeri bir nesnenin içine çıkış başvurulan belgenin kimliği 'göster o belgeleri içerecek şekilde' sorgu param çıktı küçült/:. include_docs eğer

{"rows":[
  {"key":["123412804910820", "post"], "value":null},
  {"key":["123412804910820", "author", "Lance1231"], "value":{"_id":"Lance1231"}},
  {"key":["123412804910820", "comment", "comment1"], "value":{"_id":"comment1"}},
  {"key":["123412804910820", "comment", "comment2"], "value":{"_id":"comment2"}}
]}

İle aynı görünüm isteyen '?include_docs=true' ekler 'doktor' anahtar olacak ya da '_ıd' başvurulan 'değer' nesne ya da olur mu şimdiki 'value' nesne kullanılır ('_ıd' belgeden hangi satır olduğunu yayılan (bu durumda 'post' belge). Lütfen unutmayın, bu sonuçlar bir 'kimlik' alanına hangi yayarlar yapıldı kaynak belge başvuru. yer alacak Bu alanı ve okunabilir olması için bıraktım.

Biz daha sonra kullanabilirler 'start_key' ve 'end_key' filtre parametreleri için sonuçlar aşağı bir tek post data:

?start_key=["123412804910820"]&end_key=["123412804910820", {}, {}]
hatta özellikle özü listesi için belli bir türü:
?start_key=["123412804910820", "comment"]&end_key=["123412804910820", "comment", {}]
Bu sorgu param kombinasyon mümkün, çünkü boş bir nesne ("{}") Her zaman en altta yer alan harmanlama ve null veya "" her zaman zirvede.

Bu gibi durumlarda CouchDB ikinci yararlı ayrıca _list işlevidir. Bu izin için yukarıdaki çalışma sonuçları ile bir şablon sistemi Bir tür (HTML, XML, CSV ya da her neyse geri), veya çıkışı birleşik bir JSON yapısı olmak istiyorsan mümkün isteği bütün bir yazı içeriği (dahil olmak üzere yazar ve yorum veri) ile bir tek isteği ve iade olarak tek bir JSON belge maçlar ne istemci tarafı/UI kod gerekiyor. İşin bu izin isteği sonrası Birleşik çıkış belgesi bu şekilde:

/db/_design/app/_list/posts/unified??start_key=["123412804910820"]&end_key=["123412804910820", {}, {}]&include_docs=true
_list işlev (bu durumda adında "Birleşik") Ara sonuçları haritada göster/azaltmak (bu durumda adında "mesaj") ve çalıştırmak için onlara bir JavaScript işlevi bu geri gönder HTTP yanıt içerik türü gerekir (JSON, HTML, vb.).

Bunları birleştirerek, bölünmüş belgelerinin her düzeyde bulmak yararlı ve "güvenli" için güncelleştirmeleri, çatışmalar, çoğaltma, ve sonra onları tekrar bir araya koymak gibi gerektiğinde onlar istedi.

Bu yardımcı olur umarım.

Bunu Paylaş:
  • Google+
  • E-Posta
Etiketler:

YORUMLAR

SPONSOR VİDEO

Rastgele Yazarlar

  • BioHunta

    BioHunta

    28 Mayıs 2006
  • kourtneyannmakeup

    kourtneyannm

    19 ŞUBAT 2012
  • Neil Cicierega

    Neil Ciciere

    22 Mart 2006