E ticaret sitelerindeki kategorizasyon ve özellik tanımlamaları

Merhaba

Ana kategori tablosu, ve buna bağlı alt kategoriler tablosu olması daha iyi olur. ID ler ile bağlantı kurarsınız. Alt kategori tablosununda altında da ürün özellikleri de ayrı tablolarda tutulabilir. 

Arama için In olabilir

Yavuz Bey, kategori tabloları sıklıkla değiimez bildiğiniz üzere, yani değişse de çok fazla alan kaplamaz. Misal diyelim ki max 50 MB olduğunu düşünün. Buna bile dünyanın kategorileri sığar.

1) Böyle static (en azından durağan a yakın veriler için) ben verilerin ram de tutulmasını tercih ederdim. Ama gelin görün ki, hız kaygısı ile ram de depolanan verilere işlem gücü kullanarak sql algoritmasından mahrum şekilde erişmek, sql ile erişmekten daha yavaş olabiliyor. Yani sonuçta C# da sql gibi bir algoritma var mı (indexlenmiş veriler için Balanced tree kullanıyor sanırım sql) C# da buna benzer bir yetenek bir şablon ya da iterasyon var mıdır haberim yok açıkçası.

(Sizce :))

2) Bunun yerine sql ile connection (veri trafiği açısından maliyetli) bağlantı kurarak kategorileri verilerini talep etmek gerektiğinde, sql e hem non-clustered index hem de tabloları SSD de değil, ramde depola gibi bir komut / yapılandırma kullanabiliyor muyuz ? Var mıdır? Verilerin yazımı için RAM biraz riskli çünkü elektrik kesintisinde kayıt olmamış veriler mevcut olabilir ama en azından OKUMA işlemi için kullanılabilecek bir seçenek var mıdır ?

Sonuçta SSD 500 MB/s ama RAM 20 - 30 GB/s ...

Teşekkür ederim.

Merhaba

Sql serverda In-memory table ları araştırabilirsiniz, index tarafında ise index ler içi bir filegroup oluşturup bunu ssd disk üzerinde konumlandırabilirsiniz. In memory tabledaki indexler, klasik indexlerden farklıdır, disk üzerinde tutulmuyorlar.

Teşekkür ederim. Bir kitap satın aldım ve bazı kıstlamalar olduğunu öğrendim. Örneğin foreign key in desteklenmemesi gibi. Peki foreign key in memory tablolarda desteklenmiyor; RAM de olan tablodaki Primary Key kolonuna diskte olan tablodaki Foreign Key kolonu referans verebilmekte midir ?

Merhaba

Sql serverda In-memory table ları araştırabilirsiniz, index tarafında ise index ler içi bir filegroup oluşturup bunu ssd disk üzerinde konumlandırabilirsiniz. In memory tabledaki indexler, klasik indexlerden farklıdır, disk üzerinde tutulmuyorlar.

Merhabalar,

Önerilerinizi harfiyen uyguladım. Bir iki yerde problem yaşadım örneğin filename belirtirken %HomeDrive%/DosyaAdi deklarasyonu beni hayal kırıklığına uğrattı çünkü çalışmıyor :(( %HomeDrive% ifadesini nasıl anlamadığına şaşırdım.

Ve aklıma şu soru takıldı; "SHEMA_AND_DATA diyoruz, böylece hem şemanın hem de verinin diskte olası enerji kesilmelerine karşı kaydedilmesini istiyoruz. Ama, INSERT ya da UPDATE durumunda, eklenen ya da silinen veriler ne kadar süre sonra diskteki kopyaya yansımaktadır ? Hemen mi, yoksa belli aralıklarda ya da özel bir yapılandırması mevcut mudur ?"

Kanımca, hemen yansımamaktadır, çünkü böyle olsaydı INSERT ya da UPDATE çok hızlı çalışmayacaktır. Sanırım bu tip tabloların başlıca dezavantajı RAM kapasitesi ve Enerji kesildiğinde tablonun diskteki kopyasına henüz yansımamış veriler olma riski.

Peki neden memoryde tutulan tablo primary key için bucket_count belirtmek zorundayız ? Ben şahsen belirtmiyorum bilmem otomatik bir değeri var mı, duruma göre kendi kendini ayarlayabilen bir mekanizması mevcut mudur, bilemiyorum. Bir de sanırım sorgu yaparken From Table den sonra WITH (SNAPSHOT) biçiminde izolasyon modunu belirtmek zorunda olunması... Galiba belirtilmeyince sorgu hızı avantajından mahrum kalınıyor.

Saygılar, teşekkürler.