[perplex]

Merhaba,

Bir arkadaşlık sitesinde arkadaş listesi oluştururken db dizaynını nasıl yapmalıyım? Üyeler arkadaş olmak istedikleri üyeye talep göndericekler o şekilde kabul edilirse arkadaş olabilecekler.

Üyeler tablosunda arkadaşlarım,talep ettiklerim, talebimi isteyenler gibi 3 ayrı sütun açıp buraya ilgili id'leri virgüllerle yazmak geldi aklıma ama sanki daha pratik bir yöntemi var.

[meteryus]

o üç ayrı sütunu kapsayan yeni bir tablo oluşturun bu tablodaki extra bir bölüm ile kullanıcılar tablosu ile ilişkilendirin.

tablo : arkadaş listesi
-------------------------------------------------------------------------
id | talep ettiklerim| talebimi isteyenler | arkadaşlarım | kullanıcı

gibi.

[perplex]

meteryus tarafından gönderilen mesaj:

o üç ayrı sütunu kapsayan yeni bir tablo oluşturun bu tablodaki extra bir bölüm ile kullanıcılar tablosu ile ilişkilendirin.

tablo : arkadaş listesi
-------------------------------------------------------------------------
id | talep ettiklerim| talebimi isteyenler | arkadaşlarım | kullanıcı

gibi.

ama id leri virgüllerle peşpeşe yazma mantığı aynı yine. başka bi yöntem varmıdır acaba. her seferinde id'leri explode/split edip arrattırmak zaman harcatıcakmış gibi geliyor.

[meteryus]

neden idleri peş peşe virgülle ayırarak yazman gerektiğini anlamadım ? bu tabloya dolu olması gereken her bölüm için bir satır ekle, kullanıcı kısmına da kullanıcının idsini yaz.

[perplex]

meteryus tarafından gönderilen mesaj:

neden idleri peş peşe virgülle ayırarak yazman gerektiğini anlamadım ? bu tabloya dolu olması gereken her bölüm için bir satır ekle, kullanıcı kısmına da kullanıcının idsini yaz.

sanırım ayrı id'lerden bahsediyoruz .)

bir örnek verim: mesela benim id'im 24 , 5 tane arkadaşım 2 arkadaşlık teklifim bana yapılan da 3 arkadaşlık teklifi var o halde arkadaslar tablosu

id kullanıcıid arkadaslar talep_ettiklerim talebimi_isteyenler
---- ------------- ------------- ------------------- -----------------------
1 24 12,20,21,34,45 54,64 30,55,76

vs. şeklinde olcak.

ben bu şekilde anladım yanlış anlamadıysam. ama işte mesela arkadaşlık talebim onaylandığında array'i ayıklayıp talep sütunundaki id 'yi arkadaş sütünuna almak kasıcakmış gibi geliyor. daha kolay bir yolu varmı onu arıyorum.

[meteryus]

id | kullanıcıid | arkadaslar | talep_ettiklerim | talebimi_isteyenler
1 | 24 | 32 | |
1 | 24 | 11 | |
1 | 24 | 43 | |
1 | 24 | 23 | |
1 | 24 | | 323 |
1 | 24 | | 123 |
1 | 24 | | | 33
1 | 24 | | | 221
1 | 24 | | | 321
1 | 24 | | | 11

ben bu şekilde düşünmüştüm (tabi forumda boşluklar çıkmadığı için biraz karmaşık göründü ) ama bu şekilde mesela "SELECT talebimi_isteyenler FROM tablo WHERE kullaniciid=24" gibi sorgularla verilere ulaşabilirsiniz.

[emreyuce]

Merhaba,

Forumda ilk mesajım

Bence üyeler tablosunu ve talep tablosunu ayırmalısın. @meteryus'un söylediği de bu sanıyorum. Yani "üyeler" tablosunda id,uye_adi,... olacak.

Bir de "talep" tablosu yap, onda da id,tale_eden_id,talep_edilen_id olacak. "talep" tablosunda tekil anahtar olarak "talep_eden_id+talep_edilen_id" kullanmalısın. Yani bu iki özellik aynı değere birden fazla kere sahip olmamalı.

"arkadaslarim" tablosunu da böyle tasarlayabilirsin

Umarım yardımcı olur.

[kArA]

Ben de emreyuce'ye katılıyorum. Kullanıcılar ve Talepler tablolarını ayırmak iş mantığı açısından da verimli olacaktır. (talepler tablosundaki durum alanı için tinyint yerine enum da kullanılabilir)

CREATE TABLE kullanicilar (
  Kullanici_Id int(10) unsigned NOT NULL auto_increment,
  Kullanici_Adi varchar(16) NOT NULL,
  PRIMARY KEY  (Kullanici_Id)
);

CREATE TABLE talepler (
  Talep_Eden_Id int(10) unsigned NOT NULL,
  Talep_Goren_Id int(10) unsigned NOT NULL,
  Durum tinyint(1) NOT NULL,
  PRIMARY KEY  (Talep_Eden_Id,Talep_Goren_Id)
);

talepler tablosundaki Durum alanı talebin hangi aşamada olduğunu bildirir. Yeni talep, kabul edildi, reddedildi vb.
Bu tablo sayesinde bir kullanıcıya gelen talepleri, bir kullanıcının yaptığı talepleri, taleplerin kimlere yapıldığı, kimlerden geldiği ve durumları gibi bir çok bilgiye kolayca ulaşabilirsiniz. Bu tip bir tablo hem gereksiz veri kalabalığını engellediği gibi isterseniz geriye dönük istatistiksel veri de sunabilir.