Verilerimin ilişkisel veya nesne yönelimli olduğunu nasıl bilebilirim?

Sadece şu satırları okuyun-

• Verileriniz doğadaki bir nesne ise, nesne depolarını ("NoSQL") kullanın. İlişkisel bir veritabanından çok daha hızlı olurlar.

• Verileriniz ilişkisel nitelikte ise, ilişkisel veritabanının ek yükü buna değer.

dan-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Peki, verilerimin doğası gereği ilişkisel mi yoksa nesne odaklı mı olduğunu nasıl bilebilirim?

Parçalara ayrılma riski altında, basit bir İngilizce tanımı deneyeceğim.

Benim için "İlişkisel doğa" şu anlama gelir: belirli bir türdeki tüm öğeler hemen hemen aynı özelliklere sahiptir, bu da basit bir tablo tasarlamayı oldukça kolaylaştırır, ancak CRUD ve geri alma işlemini gerçekleştirmek için bu tabloya ve sonra SQL'e tüm öğeler. Ayrıca, verileriniz tüm öğelerin sınırlı türden birine sahip olacağı şekilde modellenebiliyorsa, bu tür kümelere karşılık gelen ilişkisel bir veri yapısı tanımlayabilirsiniz.

"Nesne doğası" şu anlama gelir: Benzer tipteki öğeler çok çeşitli özelliklere sahip olabilir ve bu özellikler çok çeşitli türde ve nitelikte olabilir. Çoğu zaman bu (yeterli çaba ile) ilişkisel bir modele çevrilebilir, ancak tabloların birçoğu çok seyrek olarak doldurulur ve çok verimli olmayan bir LEFT OUTER birleşimleriyle sonuçlanırsınız, bu da ilişkisel bir veritabanının performansını karşılaştırır NOSQL veritabanına.

Benim görüşüme göre, bu ikisini ayıran katı bir çizgi olmadığını söylemeliyim. Muhtemelen iki uç arasında herhangi bir yere düşen çok sayıda örnek bulabilirsiniz.

Tamam, şimdi kendimi her yönden keskin nişancılara açtım. Herhangi bir yorum hoş geldiniz. Bu tanımı birlikte geliştirip geliştiremeyeceğimizi görelim.

Verilerin ikisi de.

(Açıkçası, doğada nesne olamaz çünkü davranıştan yoksundur, ancak nitpick yapmayacağız).

Verilerin RDBMS veya NoSQL veritabanında depolanmasına ilişkin kararlar , verilerin gerçek 'doğası'ndan ziyade , verileri nasıl kullanmayı planladığınıza bağlıdır .

Verilere yönelik her türlü gezinme yolunu desteklemek istiyorsanız, verilere erişmek ve sunmak için farklı yollara sahip olacağınız için verileri bir RDBMS'de depolamak isteyebilirsiniz. Sizin için bir sürü ağır kaldırma yapmak için veritabanına ihtiyacınız var. Örneğin, 'Sipariş' verilerine müşteri, satış elemanı, sku (öğe), tarih, bölge vb. Aracılığıyla erişilebilir.

Öte yandan, minimum gezinme yollarınız varsa, tüm nesneyi depolayabilirsiniz. Örneğin, yalnızca web kullanıcı arabirimi tarafından erişilen ve uzun süre depolanmayan veya çok fazla analiz edilmeyen 'Sepet', bir NoSQL mağazasına daha uygun olabilir. NoSQL veri depolarıyla (belge veya anahtar değeri) yaptığınız fedakarlık, koleksiyonlar arasındaki ilişkiler olmadan yapmaktır - bu ilişkilere ihtiyacınız yoksa (gezinme yolları, geçici sorgulama veya raporlar için) ve uygulaması, o zaman iyi olacak.

Tabii ki, verileri farklı nedenlerle saklayabilirsiniz, ancak bunun kendi dezavantajları vardır.

Veriler 'doğada nesne' veya 'doğada ilişkisel' değildir. Her türlü veri hem ilişkisel hem de nesne modeli / grafik yapısında temsil edilebilir. Uygun olan, verilerin uygulamalar tarafından nasıl kullanılacağına bağlıdır. Genellikle her ikisine de sahip olabilirsiniz. Örneğin, bir web sitesinde kullanılan veriler ilişkisel bir veritabanında saklanabilir, ancak isteğe bağlı olarak daha sonra bir bellek içi anahtar / değer deposunda önbelleğe alınan bir grafik yapısına yüklenebilir.

Nesne depolar / NoSql bazı tür veriler için ilişkisel daha hızlı olacaktır deyimi yanlıştır. Önemli olan yine uygulamanızın verileri nasıl kullandığıdır , verilerin biçimini değil. Bir nesne deposu, birim olarak depolanan bir nesne grafiğini yükleme konusunda daha hızlı olacaktır, ancak birçok nesne arasında geçici sorgulama yaparken veya birçok nesnenin özelliklerini güncelleme konusunda çok daha yavaş olacaktır.

Ben makalede anahtar satır olduğunu düşünüyorum:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Bana göre yazar iyi bir noktaya işaret ediyor, eğer kodunuz örneğin İspanya'daki müşteri sayısını bir miktar mantık için alıyorsa, İspanya'daki tüm müşterilerle bir müşteri listesini doldurmamanız ve daha sonra müşteri nesneler. (hangi bir ORM sizi size doğru yönlendirebilir)

Açıkçası müşteri veri yapısının kendisinden böyle kullanıp kullanamayacağını anlatamazsınız. bu yüzden 'verileri', 'uygulamanız tarafından kullanılan tüm bilgiler' anlamına gelecek şekilde yorumlamamız gerektiğini düşünüyorum. Bu, toplamalar veya 'Y ile ilgili Tüm X' gibi şeyleri içeriyorsa, 'verileriniz' atomik NoSql yaklaşımı için uygun değildir