[]
SQL sorusu
Direk maruzatima geciyorum. Simdi cok basit bir tablom var kullaniciNumarasi, Ismi ve bi takim seyler tutuyor diyelim. Facebook gibi dusunebiliriz ama kimin kimle arkadas oldugunu tutan bir tablo yok. Sonra bana bir kullanici icin text formatinda(daha dogrusu database'den bagimsiz) arkadaslarinin listesi geliyor. Eger adamin 1000 tane arkadasi varsa ben bu arkadaslarinin bilgisini WHERE kisminda OR ile yazarsam query cigrindan cikar.
Bu asamada en randimanli nasil yapilir konusunda onerilere acigim.
Tablolarda degisiklik yapabilirim ve arkadas bilgisi tutabilirim ama o zamanda database sanki cigrindan cikar gibi geliyor. Zira facebook application'i olacak ve ortalama 300 arkadasi olsa bir kimsenin kabaca bir hesapla 1000 kullanicida 300000lik bir tablom olur. arkadas1->arkadas2 seklinde. Gerci tablo 2 kolonlu ve super indexlemeye uygun tabii.
Bir alternatifde acaba kullanici bilgisi tablosuna bi text alani acip oraya arkadaslarinin kullaniciNumaralarini yanyana yazdirip sonra metin aramasi mi yapsam dedim. Bu son oneri cok bodozlama ve database mantigina direk aykiri onun farkindayim.
Query'nin WHERE kisminda facebook'da tutulmayan bazi bilgiler koyacagim kendi tablomda olmasi lazim bu islerin.
saygilar
edit: En kolay soyle aciklim. Facebook kullanici tablosunda 2 kolon daha tutmam lazim. Bunlar diyelim adamin boyu ve kilosu. Adam application'a girdiginde ben adamin arkadas listesini facebook'dan alabiliyorum kendi database'ime bi is yaptirmam gerekmiyor ama boy ve kilo bilgisi benim tablomda tutuluyor facebook'da tutamayacagim icin.(aslinda bole onlarin bi arada data API olayi vardi noldu bilmiyorum)
Benim tablomda sadece kullanicinin facebookId'si boyu ve kilosu tutuluyor suanda diyelim.
Bu asamada en randimanli nasil yapilir konusunda onerilere acigim.
Tablolarda degisiklik yapabilirim ve arkadas bilgisi tutabilirim ama o zamanda database sanki cigrindan cikar gibi geliyor. Zira facebook application'i olacak ve ortalama 300 arkadasi olsa bir kimsenin kabaca bir hesapla 1000 kullanicida 300000lik bir tablom olur. arkadas1->arkadas2 seklinde. Gerci tablo 2 kolonlu ve super indexlemeye uygun tabii.
Bir alternatifde acaba kullanici bilgisi tablosuna bi text alani acip oraya arkadaslarinin kullaniciNumaralarini yanyana yazdirip sonra metin aramasi mi yapsam dedim. Bu son oneri cok bodozlama ve database mantigina direk aykiri onun farkindayim.
Query'nin WHERE kisminda facebook'da tutulmayan bazi bilgiler koyacagim kendi tablomda olmasi lazim bu islerin.
saygilar
edit: En kolay soyle aciklim. Facebook kullanici tablosunda 2 kolon daha tutmam lazim. Bunlar diyelim adamin boyu ve kilosu. Adam application'a girdiginde ben adamin arkadas listesini facebook'dan alabiliyorum kendi database'ime bi is yaptirmam gerekmiyor ama boy ve kilo bilgisi benim tablomda tutuluyor facebook'da tutamayacagim icin.(aslinda bole onlarin bi arada data API olayi vardi noldu bilmiyorum)
Benim tablomda sadece kullanicinin facebookId'si boyu ve kilosu tutuluyor suanda diyelim.
Şimdi kullanıcı tablo listeni düşün. id, kullanici_adi, sifre, adsoyad, email, kolonları olsun. id auto verilsin. Şimdi diyelimki benim id'im 396. Senin id'in ise 521 olsun. judagor mesela 666 olsun. :P
İkinci tablomuz arkadaslar. Onda şu alanlar olsun. userid, arkadasid. Şimdi ben seni arkadaş listeme eklediğim zaman arkadas tablosunda userid kısmına benim id'im olan 396, arkadasid kısmına ise senin id'in 521 gelsin. Judagor'u eklersem 666 yazsın.
arkadas tablosu
----------------
userid arkadasid
-------- -----------
396 521
396 666
şeklinde.
İkinci tablomuz arkadaslar. Onda şu alanlar olsun. userid, arkadasid. Şimdi ben seni arkadaş listeme eklediğim zaman arkadas tablosunda userid kısmına benim id'im olan 396, arkadasid kısmına ise senin id'in 521 gelsin. Judagor'u eklersem 666 yazsın.
arkadas tablosu
----------------
userid arkadasid
-------- -----------
396 521
396 666
şeklinde.
- pichoscosama2
(01.10.09 00:16:27)
pichoscosama2
ortalama 300 arkadasli bir ortamda 1000 kullanicida 300000lik bi tablo olacak ki 1000 kullanici oldukca az bir deger. mysql'in randimani nasil olur diye dusunuyorum. Birde arkadas ekleme kismi facebook'da olacak, neyse bu ayri bi konu ama facebook ile ayni guncellikte tutmam gerekiyor bu listeyi.
ortalama 300 arkadasli bir ortamda 1000 kullanicida 300000lik bi tablo olacak ki 1000 kullanici oldukca az bir deger. mysql'in randimani nasil olur diye dusunuyorum. Birde arkadas ekleme kismi facebook'da olacak, neyse bu ayri bi konu ama facebook ile ayni guncellikte tutmam gerekiyor bu listeyi.
- badseed (01.10.09 00:20:29)
buradaki arkadas kişi eşleştirmesi tam bir one to many relation degil, onu gözden kacırmamak lazım. mesela kişi telefonlar eslesmesi olsa kişi id ile telefonları 2. tabloda one to many relation'la tutarsın. ama burada 2. tablo ile gelen verilerde aslında 1. tablonun parcası yani, pichoscosama2 nın verdigi ornekten gidersek, 396 521 kaydının yanında 521 396 diye de bir kayıt bulunması lazım eger bu sekilde bir relation kurulacaksa. bodoz text tuttugunu dusun (aman diyim) bu seferde gidip hem 1. kisinin arkadaslar verisinde 2. yi, hemde 2. nin arkadaslar verisine 1. yi girmiş oluyorsun. arkadaslık ilişkisi ikileniyor otomatik olarak o yuzden az biraz daha farklı bir relation mantıgı kurmak gerekli.
şu stackoverflow.com ve şu stackoverflow.com işini görebilir bilgi vermesi açısından.
şu stackoverflow.com ve şu stackoverflow.com işini görebilir bilgi vermesi açısından.
- 8 ortali harita metod defter
(01.10.09 00:36:30)
aslına bakarsan [396 , 521] şeklinde tutmak yeterli iki kolonda çünkü biri arkadaşlığı bitirdigi zaman digeri de otomatikman bitirmiş oluyor , öyle bir durumda veriyi başka bir tabloya transfer edip bunlar eskiden arkadaşmış diye log da tutabilirsin ve arkadaş tablosundan silebilirsin.
(tabi bu aşamada diğer tabloya taşımak ardından silmek maliyetli bir işlem olabilir , onun yerine arkadaşlar tablosuna bir alan koyup statusunu güncelleyerek bunlar arkadaş degil olarak işaretleyebilirsin , sonrada system loadın düşük oldugu saatleri saptayarak o saate bir job koyarsın , batch olarak statusu silinmiş olarak işaretlenenleri silersin)
facebook idleri için bigint ideal gözüküyor ayrıca güzel de bi indexledigin zaman milyonlara kadar yolu var mysql'in pek ses edecegini sanmıyorum üzerinde çok kompleks sorgular yazmayacaksan , gayet iki tabloyu inner join ile efendi efendi birleştirip kullanabilirsin , hatta view bile kullanabilirsin.
Ama böyle bir durumda cross joinden kaçınmak iyi olabilir.
Özetle ben de mutlaka 2. bir tablonun gerekli olduğunu düşünenlerdenim , en azından normalizasyon kuralları da böyle diyor.
Son olarak bu insanların arkadaş listelerini sürekli güncelleyecegini düşünürsek sen de aynısını yapmalısın , bu durumda periyodik olarak ağır sorgular çalıştıracaksın bu tablolarda.
belki aynı dataları farklı bir tablo ile senkronize tutup , production tablosundan sadece select yapılmasını sağlayarak runtime için biraz zaman kazanabilirsin.
(tabi bu aşamada diğer tabloya taşımak ardından silmek maliyetli bir işlem olabilir , onun yerine arkadaşlar tablosuna bir alan koyup statusunu güncelleyerek bunlar arkadaş degil olarak işaretleyebilirsin , sonrada system loadın düşük oldugu saatleri saptayarak o saate bir job koyarsın , batch olarak statusu silinmiş olarak işaretlenenleri silersin)
facebook idleri için bigint ideal gözüküyor ayrıca güzel de bi indexledigin zaman milyonlara kadar yolu var mysql'in pek ses edecegini sanmıyorum üzerinde çok kompleks sorgular yazmayacaksan , gayet iki tabloyu inner join ile efendi efendi birleştirip kullanabilirsin , hatta view bile kullanabilirsin.
Ama böyle bir durumda cross joinden kaçınmak iyi olabilir.
Özetle ben de mutlaka 2. bir tablonun gerekli olduğunu düşünenlerdenim , en azından normalizasyon kuralları da böyle diyor.
Son olarak bu insanların arkadaş listelerini sürekli güncelleyecegini düşünürsek sen de aynısını yapmalısın , bu durumda periyodik olarak ağır sorgular çalıştıracaksın bu tablolarda.
belki aynı dataları farklı bir tablo ile senkronize tutup , production tablosundan sadece select yapılmasını sağlayarak runtime için biraz zaman kazanabilirsin.
- alwaysdrunk (01.10.09 12:07:09 ~ 12:38:33)
1
