bluepea
simdi arkadaşlar, facebook kullanmayan biri olaraktan cahilliğimi bağışlayın. bu yazdığımız entrylerin facebook'da paylaşıldığını anlamamızın bi yolu var mı? yani nasıl anlayacağız paylaşıldığını?
simdi arkadaşlar, facebook kullanmayan biri olaraktan cahilliğimi bağışlayın. bu yazdığımız entrylerin facebook'da paylaşıldığını anlamamızın bi yolu var mı? yani nasıl anlayacağız paylaşıldığını?
0
zannetmiyorum. çünkü fb butonu sadece ilgili entry'ye bir link veriyor facebook üzerinden.
0
wiki.developers.facebook.com
buradaki api ile öğrenmek mümkün, bu api ile çalışan bi uygulama da vardır illaki
buradaki api ile öğrenmek mümkün, bu api ile çalışan bi uygulama da vardır illaki
0
badseed
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 li
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.
0
Ş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.
0
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.
0
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.
0
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.
0
8 ortali harita metod defter
90'lı yıllarda bilgisayar dergilerinin cd lerinde bolca dağıtılan bir uçak oyunu vardı. sanırım freeware bir oyundu. oyunda 2 boyutlu bir alanda 2 tane eski uçak olurdu, klavyeden 2 kişi bu uçakları yönetirdi. sadece gaz ve alçal-yüksel tuşları olurdu. bir de ateş etmek için bir buton. adını hatırla
90'lı yıllarda bilgisayar dergilerinin cd lerinde bolca dağıtılan bir uçak oyunu vardı. sanırım freeware bir oyundu. oyunda 2 boyutlu bir alanda 2 tane eski uçak olurdu, klavyeden 2 kişi bu uçakları yönetirdi. sadece gaz ve alçal-yüksel tuşları olurdu. bir de ateş etmek için bir buton. adını hatırlayan varmıdır ?
0
wings of fury de degil carrier air wing de, bu oyun platform oyunu gibi degildi, sabit ekranda 2 tane uçak, aynı bu iki oyundaki gibi dikey eksende 2 boyutlu olarak savasırdı. kurukafa da dogru hatırladı sanırım, surekli takla felan atardınız oyunda ama gazı ve açıyı dogru ayarlamasanız stall felan bile oluyordu. yok mudur baska tahmin ?
art of flying felan gibi bi adı vardı diye bişeyler var aklımda ama duzgun bir sonuc cıkmıyor
art of flying felan gibi bi adı vardı diye bişeyler var aklımda ama duzgun bir sonuc cıkmıyor
0
buldum sonunda, oyunun adı triplane www.homeoftheunderdogs.net birileri oturup yenilemiş oyunu o da dogfight www.homeoftheunderdogs.net ikisi de freeware oyunlar
0
sathaner
Explorer her sayfada bu hatayı veriyor iş yeri bilgisayarında, İE7 yüklettim yine düzelmedi, nasıl düzlticem bu sorunu, varsa bir pratik yolunu bilen çok yararlı olacak.
Explorer her sayfada bu hatayı veriyor iş yeri bilgisayarında, İE7 yüklettim yine düzelmedi, nasıl düzlticem bu sorunu, varsa bir pratik yolunu bilen çok yararlı olacak.
0
tahminen spy felan neyim yedin ondan sacmalıor cihaz. spyware doctor la yada ad-aware ile bir tarat. olmazsa eklentilerden her seyi disable et oyle dene.
0
spy falan bulaşmasına benzemiyor, zaten çalıştığım yer bilişim şirketi, korumalıdır yani, bir yazım hatası veriyor ama hala çözemedim.
0
Flash player, java patlamış olabilir ya da yüklü script patlamış olabilir sanırım.
0
