none
Veri tabanı tasarımı uygunluk ve geliştirme RRS feed

  • Soru

  • Merhabalar ben üyelik kısmını bu şekilde ayırarak yaptım sizce bu yapı doğru mu? Uyeler tablosu membership tablosundan alacağım için sadece timsali bir tablo şeklinde yaptım diğerlerin eklemem ya da çıkarmam gereken ya da ilişkilerden değiştirmem gereken yer varmıdır. 

    Görüşlerinizi bildirirseniz sevinirm.

    İyi günler

    Saygılar.Üye Bilgileri tablosu


    Yunus Emre ALTINAY


    25 Nisan 2014 Cuma 10:36

Yanıtlar

  • Turunu kendi olasi kapasitelerinle belirleyebilirsin. Genelde kullanilan integer. SQLite kullaniyor olsan default bigint. uniqueidentifier'in artisi, database'e baglanmadan bile key alabilmen.

    (100 000 000 uye hedefliyorsan, adam basi ortalama 10 adres hesabiyla 1 milyar adres ID gerekir, bunu integer karsilar).

    Not: Telefon tablosunu anlamama nedenim telefonNo olmamasi idi :) Eger o telteltur, telefon no ve tur ise o zaman daha kotu. TelefonNo basli basina tartisma konusu zaten. Kimine gore mask olmali ve sadece rakam icermeli, kimine gore ise (mesela bana gore) serbest olmali - TRKCELL diye kaydedebilmek isterim.

    25 Nisan 2014 Cuma 14:55

Tüm Yanıtlar

  • Uyelik sisteminde neler tutmak istedigini ben bilemem tabii :) Sadece mevcut semana bakinca gordugum potansiyel hatalari not etmek istedim:

    Sehirler - Ilceler, 1-Cok iliskili. Guzel, ancak UyeDetaylari tablosu ile ikisi de 1-Cok iliskilendirilmis ve UyeDetaylari tablosunda hem sehir hem de ilceID var. Bu tekrarlama demektir ve potansiyel hata noktasi. Her sehirID ya da ilceID degeri degisikliginde, digerinin de dogru sekilde guncellendiginden emin olman gerekecek. Oysa hali hazirda Sehir-Ilce iliskisi var ve bu iliski uzerinden, ilceId biliniyorsa SehirID biliniyor demektir. Yine ayni yerdeki potansiyel mantik hatasi, adres(ler) ile iliskili. YasadigiSehirID, YasadigiIlceID var, bir de 1-Cok iliskili adres tablosu (ve adres tablosunda yine potansiyel hatali sehirId, ilceId). Eger adres yasadigi yer bilgisini veriyorsa bu hata degil mi (nufusa dayali secim sistemimiz belki de boyle bir sema kullaniyor da ondan hic saglikli secim olamiyor, kim bilir - kedilerin katkisi ayri).

     
    25 Nisan 2014 Cuma 12:33
  • Merhabalar;

    Bu benim aklıma hiç gelmemişti. Zaten ilçe id değerini kaydettiğimiz zaman o ilçenin hangi ile bağlı olduğunu çekebiliriz. Peki bu şekilde yapsam sorgu esnasında performans kaybı yaşar mıyım?

    Birde eğer adres yaşadığı yer bilgisini veriyorsa demişsiniz. Benim orada sehir ve ilçeyi koymamdaki amaç o kişinin anne, baba, arkadaş,akraba gibi başka kişi bilgilerini tutmak için koydum. Yani kişi antalya da oturuyor bilgisini vermek istediği kişi farklı bir ilde oturuyordur şeklinde düşünerek yaptım. Sanırım ordaki sehir ve ilçe alanını silip sadece ilçe eklemek sorunu düzeltecektir.

    Teşekkürler.


    Yunus Emre ALTINAY


    25 Nisan 2014 Cuma 13:00
  • Performans kaybi yasar misin bilemem. Olayi cok fazla kita, ulke seklinde parcalamissin, ister istemez bir suru join olacak. NoSQL databaseler ile bu joinler gerekmedigi icin yasamazsin ama SQL serisinde joinler kacinilmaz. Kendi adima boyle bir uyelik sistemini NoSQL ile yapmak isime gelir.

    SQL serisi databaselerde, performans acisindan ( ben bunu yapiyor olsaydim ) muhtemelen hic kita, ulke, sehir, ilce tablolariyla ugrasmazdim. Onun yerine kisilerin adres bilgilerinden bunu sabit tablolardan ya da servislerden cozumlerdim (bu kisim kisilerin yazacagi seyler degil, internetde bazen ucretli bazen ucretsiz tonlarca geo database var, ya da ornegin google maps servisleri adresten detaylari buluyor). 

    Adres - yasadigi yer aciklamasini anlamadim, kusura bakma :)

    Not: Gereksiz bir bilgi ama, bu kadar kita, ulke .... parcalamasina gittiginde, bazi ulkelerde bizimki gibi "ilce" kavrami yok. Ornegin ABD'de county, province, city, town gibi siniflamalar var. Orada isin cok zor olacak gibi geliyor. Sanki biraz GIS ile karistirmissin isi.

    Bu arada, telefon tablonu da hic anlamadim:)

    25 Nisan 2014 Cuma 13:50
  • Aslında Kıta, Ülke gibi alanlarda seçme,güncelleme tarzı şeyler olmayacak en çok kullanılacak tablolar sehir, ilçe zaten hergün yeni şehir ya da ilçe kurulmadığı için sadece bu tablodan seçme işlemi yapılır.

    Telefon tablosuda aynı adres tablosu gibi anne,baba,arkdaş,akraba ayrı ayrı hangi telefon kimin şeklinde açıklama satırına yazılacak(isimlendirme yanlış olabilir aklıma o geldiydi),

    TelTur ise Ev,İş,Cep tarzında bilgi tutuyor. belki gereksiz ama lazım olur diye bu şekilde yaptım.

    Birde mesala telefon veya adres tablosunda bigint veri türünü kullanıyorum doğrumu sizce ya da hangisi kullanmam gerekiyor.

    Mesala hergün binlerce kayıt girilen uygulamalarda tür ne oluyor. uniqueidentifier bu tür mü kulllanılıyor?

    Teşekkürler.


    Yunus Emre ALTINAY

    25 Nisan 2014 Cuma 14:04
  • Turunu kendi olasi kapasitelerinle belirleyebilirsin. Genelde kullanilan integer. SQLite kullaniyor olsan default bigint. uniqueidentifier'in artisi, database'e baglanmadan bile key alabilmen.

    (100 000 000 uye hedefliyorsan, adam basi ortalama 10 adres hesabiyla 1 milyar adres ID gerekir, bunu integer karsilar).

    Not: Telefon tablosunu anlamama nedenim telefonNo olmamasi idi :) Eger o telteltur, telefon no ve tur ise o zaman daha kotu. TelefonNo basli basina tartisma konusu zaten. Kimine gore mask olmali ve sadece rakam icermeli, kimine gore ise (mesela bana gore) serbest olmali - TRKCELL diye kaydedebilmek isterim.

    25 Nisan 2014 Cuma 14:55
  • Yazarken yanlışlık olmuş şimdi fark ettim

    Ordaki değer

    Tel nvarchar(15)  -- genelde böyle yapıyorum

    TelTur  -- nvarchar(30)

    Yardımınız ve önerileriniz için teşekkür ederim.

    Saygılar.


    Yunus Emre ALTINAY

    26 Nisan 2014 Cumartesi 18:09