none
Beğen Favorilere Ekle Tarzı Veriler RRS feed

  • Soru

  • Sorunumu bir örnekle açıklamam gerekirse:
    mesela bir müzik sitesi. kullanıcı müziği favorilerine ekliyor.
    kullanıcı profilinde favorilerine eklenmiş müzikler
    müziğin profilinde favorilerine ekleyen kullanıcılar listeleniyor.
    yada facebooktaki beğenenler listesi..
    kod ya da tablo olarak birşey istemiyorum.
    mantıken bu bilgiyi veritabanında müzik tablosunda mı kullanıcı tablosunda mı yoksa ayrı bir ara tablodamı tutmak kullanımı kolay performansı yüksek tercih olur?
    3 ünede ayrı ayrı kafa yordum. daha önce yapmadığım için emin olamadım. bu konuda fikirlerinizi yazarsanız sevinirim.
    1 Ekim 2012 Pazartesi 22:29

Yanıtlar

  • Haklısınız ancak performans adına veri bütünlüğü ve doğruluğundan taviz verilemez. Bu nedenle View ve StoredProcedure gibi yapılar performans ihtiyacına yönelik çözümlerdir. Buna ilaveten LIKE ve ORDER BY işlemleri (ki performansı en çok etkileyen işlemlerdendir) zaten a-z ye dizilmiş olarak saklanan INDEX alanlarda yapılmalıdır. Ya da daha doğru ifade ile ORDER BY ve LIKE çalıştırılacak alanlar INDEX'lenmelidir. Eğer text yada ntext gibi büyük alanlar ise indexleme yapılamaz bunun içinde SQL servisine yardımcı olan Text Search servisleri var bunlar devreye girmelidir.

    Buraya kadarki kısım database tarafındaki konular idi. Buna kod tarafındaki EntityFramework ve buna ait LazyLoad özelliği ile istenilen performansa ulaşılır. 

    Buttonun handlerine  "select * from a join b on id = fk" şeklinde sorgu yazıp, connection açıp veri alıp performans beklemek hayalcilik olur.


    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com
    MCC


    2 Ekim 2012 Salı 09:04
    Moderatör

Tüm Yanıtlar

  • kesinlikle ara tabloda tutulmalı

    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com
    MCC

    2 Ekim 2012 Salı 07:57
    Moderatör
  • Önay hocam bir ara bende sizinle aynı fikri paylaşırdım. Sonra biraz araştırma yaptım bu forumda bu mantığı sordum ve bana önerileri sizin ve benimde aynı düşündüğüm yapı dışında oldu. Şöyle'ki mesela favoriler kısmına göre arama yaptıracaksınız gibi düşünün; 

    "A" harfi ile başlayan müzikler, ile 100 den fazla favorisi olan müzikler gibi bir arama yapıldığını var sayalım: Böyle bir durumda INNER JOIN kullanmak zorunda kalacağız ve performans olarak bu bizi etkileyecek. Kendi veri tabanımdaki yapıyı ve ihtiyacımı anlatan bir örnek veriyim.

    Tablomda 150 binden fazla kayıt olacak (Otel). Anasayfamda bu otellerden seçili olanları 3 farklı başlık (Yurtiçi, Yurtdışı, Kıbrıs) altında  (Tab menü ile) gösteriyorum. Şimdi sizin söylediğiniz gibi ara bir tablo (anasayfaKategori) oluşturdum. Bu tabloda Başlık ve otelID bilgilerini saklıyordum. Anasayfada bu otelleri göstermek için otel tablosunun ID bilgisini teker teker arıyor ve sürekli olarak 150 bin kaydı dolaşmak zorunda kalıyordum; Yani toplam 50 otel gösterecek olsam otel tablosunu 150 bin * 50 kez dolanacaktı, yani bu yapı itibariyle of of of. 150 bin otel kaydı içerisinde hiç denemedim ama söylenilenleri yaptıktan sonra az bir kayıt olmasına rağmen gözle görülür bir fark oluştu. :) Bana önerileri otel tablosuna yeni bir kolon daha ekleyerek bütün kayıtları bir anda getirtmem oldu. Cidden çok mantıklıydı :). anasayfaKategori tablomu şu şekilde değiştirdim: Başlık ve FiltreID olarak. Otel tabloma bir kolon daha ekledim ve onunda adını filtreID olarak tanımladım :). Sonraki olay çok basit, anasayfaKategori.filtreID ile eşleşen otel.filtreID ileri otel tablosuna girip bir kerede dolanıp  aynı anda o kategoriye ait bütün otel bilgilerini çekiyordum. Yani teker teker otelID leri dolaşıp istediğim otelleri anasayfada göstermek yerine tek bir kez dolaşıp bütün otel bilgilerini bir kerede çekmek cidden performans olarak fark oldu :)

    Selim bey benim size tavsiyem müzik kolonunuzda bu bilgileri tutmak olurdu. Müzik tablonuza bir kolon daha ekleyin favoriteUser şeklinde favorilerine ekleyen kullanıcıların ID bilgilerini bu kolonda saklayın. Mesela; Selim, Önay ve Halit isimli kullanıcılar :) bu müziği beğenirlerse: 01,02,03 şeklinde verileri saklarsınız. Eğer düzgün sorgular oluşturursanız bu yapı size hiç bir sıkıntı oluşturmayacak diye düşünüyorum. Bu kesinlikle benim şahsi fikrim ve kendi edindiğim tecrübelerime dayalı bir düşünce :) Tabi ki Önay hocam bu konuda benden daha bilgilidir ama benim edindiğim tecrübe bu yönde :)


    Just a .net developer.

    2 Ekim 2012 Salı 08:53
  • Haklısınız ancak performans adına veri bütünlüğü ve doğruluğundan taviz verilemez. Bu nedenle View ve StoredProcedure gibi yapılar performans ihtiyacına yönelik çözümlerdir. Buna ilaveten LIKE ve ORDER BY işlemleri (ki performansı en çok etkileyen işlemlerdendir) zaten a-z ye dizilmiş olarak saklanan INDEX alanlarda yapılmalıdır. Ya da daha doğru ifade ile ORDER BY ve LIKE çalıştırılacak alanlar INDEX'lenmelidir. Eğer text yada ntext gibi büyük alanlar ise indexleme yapılamaz bunun içinde SQL servisine yardımcı olan Text Search servisleri var bunlar devreye girmelidir.

    Buraya kadarki kısım database tarafındaki konular idi. Buna kod tarafındaki EntityFramework ve buna ait LazyLoad özelliği ile istenilen performansa ulaşılır. 

    Buttonun handlerine  "select * from a join b on id = fk" şeklinde sorgu yazıp, connection açıp veri alıp performans beklemek hayalcilik olur.


    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com
    MCC


    2 Ekim 2012 Salı 09:04
    Moderatör
  • Önay Bey ve Halit Bey

    Kıymetli yanıtlarınız için teşekkür ederim.

    Bu konuyu düşünmeye başladığımda ara tablo kullanmak bana çok mantıksız gelmişti Halit Bey'in fikri daha mantıklı gelmişti. Ancak Halit Bey'in de verdiği örnekten yola çıkarsak müzikler tablosunda user ID yi o1,02,05,06 girdiğimizde, ve müzikler tablosu dışında videolar, şiirler, hikayeler, şeklinde sitenin diğer bölümlerinde de bu veririyi bulunduracağımızı göz önünde bulundurunca  üyenin profilinde favorilere eklediği müzikleri videoları vs. bilgisinigörüntülediğmizde veri tabanındaki hemen tüm tabloları ve neredeyse tüm satırları okutmamız gerekecektir.

    Böyle düşünüce performans açısından verdiğiniz örnekteki bütün olumlu yönlere rağmen kat kat fazla performans sorunu ortaya çıkaracağını düşünüyorum.

    Önay Bey'in önerisindeki ara tabloya gelince şu an için bulabildiğim tek çözüm bu ama aslında "sınırsız alt katagori" kodlamasının mantığındaki gibi pratik ve fazla sistemi yormayan bir çözüm yolu arıyorum. Bir favorilere ekle butonu yada sistemi sonuç olarak bir web sitesinin çok küçük bir ayrıntısıdır. o yüzden kapsamlı içeriğin bulunduğu bir web sitesinde önerdiğiniz iki yöntemde içime sinmedi. Yinede bir çözüm bulamazsam Önay Bey'intavsiyesine uyacağım. Cep telefonu aracılığıyla yazdığım için imla ve yazım hatalarından dolayı beni mazur görünüz.


    2 Ekim 2012 Salı 14:49
  • Selim bey, 

    Yanlış anlamadıysam Müzik tablosundaki bir alana, o müziği beğenenlerin id sini aralarında seperatör olacak şekilde saklamayı , ayrı tabloda saklama ile mi kıyaslıyorsunuz?

    Eğer öyle ise büyük yanlış içindeyiz demektir. Primary indexli bir alanın foreign key olarak kullanılması ile bu alanın string olarak kullanılması arasında Evrim Kuramı ve Yaradılış Düşüncesi kadar fark vardır. Bence karşılaştırma yapılamayacak bir konu. 


    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com
    MCC

    3 Ekim 2012 Çarşamba 06:08
    Moderatör