none
Mssql Tablo Yapısıyla İlgili Bir Sorum VAR !!! RRS feed

  • Soru

  • Yukaridaki gibi mssql tablolarım vs var.Yukarıdaki tablolar daha eksik 7 tane kategorim var 2 tanesini açmışım daha 5 tablo daha açacağım.Bana dün sayın Önay Yalçıner bey bilgisayarıma bağlandığında bu tablo yapısının yanlış olduğunu tek bir tabloda o kategorileri yapsaydın daha iyi olduğunu söyledi.Fakat ben bu tabloları açarken aşağıdaki sitenin dediğine inanarak açtım.Link şu : https://forum.ceviz.net/veritabanlari-amp-sql/65995-mssql-tek-tablo-kullanimi-hiz.html

    Şimdi mesela Bilgisayar tablosunun içindede birsürü alt kategori olacak pc yardim donanim yazilim vs... böyle 10-15 tane daha yani ve diğer 7 tablonun içindede böyle birsürü alt kategori olacak bunların hepsini tek bir tabloya aldığım zaman mesela en az 3bin tane kayıt açacağım farklı farklı ve daha site yayına başladığında bile 3bin satırlık veriyi tek tabloda 70 tane kategoriye bölerek(alt ile birlikte)listemiş olacak.Bunlar üzerinde belki onlarca yüzlerce kullanıcı aynı anda update,delete,insert,select sorguları yapacak çünkü interaktif bir site olacak.

    Geleyim sadete benim için 7 tablo yapmak aslında sorgularım için daha zor düşünsenize anasayfada reapter içinde farklı kategorilerden veri geleceği zaman şu komut ile tabloları birleştirip veri çekiyorum :

    select * FROM Bilgisayar UNION ALL select * FROM GuvenlikSistemleri UNION ALL select * FROM EvElektronigi) t1 INNER JOIN Kullanicilar ON t1.KullaniciID = Kullanicilar.ID Order By Tarih Desc (dahada uzayacak bu tablo diğer tablolarıda ekleyince)

    birde bunun tarihe göre sıralaması vs zor oluyor yani mssql sorgusu yazmak benim için.Ama yazarım sıkıntı yok yani.Fakat önemli olan benim sistemimim iyi çalışması

    gözle görülebilecek makul bir yavaşlık olmadığı müddetçe sıkıntı yoktur böyle düşünüyorum.Sizce ne yapmalıyım.Tek tabloda birleştirmeliyim(böylelikle sorgularım daha kolay olur) yoksa böyle kalmalımıdır ?


    16 Ekim 2014 Perşembe 08:57

Yanıtlar

  • Önay hakli.

    Oncelikle verdigin linkten baslarsak, ne yazik ki internette yazilan her sey dogru degil. Cok aciklayici olmus ama yanlis olmus, konuyu yuzeysel dusunen, veritabanlarini bilmeyen kisileri inandirir. Arkadasa basitce sormak lazim, ev ilanlari icinden tek odali olanlar icin de ayri tablo tutsak daha hizli olmaz mi diye, sonra biraz daha parcalayalim, giris kati, teras, ..., semtler icin ayri tablolar. Kisacasi her kolon icin ayri bir tablo tutalim, hiza bak (mi). Veritabanlarinda hiz o sekilde saglanmaz. Hiz icin temel olarak kullanilan indexler var. E peki dosyalarin fiziksel boyunun hic mi onemi yok? Tabii ki var, ancak databaseler de bunu dusunuyor. Sana gore tek tablo gibi gorunen bir tabloyu yatay ya da dikey parcalara ayiriyorsun (bu databasede ince ayar kismi. Database adminlerin dusunmesi gereken seyler). Bir baska yontem o "tek tablo"yu cok sayida makineye dagitmak. Arkadasin dedigi gibi fiziksel dosyanin tamaminda degil sadece icinde bulundugu fiziksel dosyada araniyor. Kullanilan database cesidine gore yontemler cok farkli. Arastirmak istersen genelde bu konuyla ilgili terimler index, indexed partition, indexed view, partitioning, sharding, distributed transaction, column store, hstore, btree, fractal tree, ... diye gider.

    Senin rakamlarin uzerinden gidersek, en az 3000 satir 5000 olsun diyelim, 70 kategori de 100 olsun. Tablonda 100 * 5000 = 500,000 kayit olur. Bu kadarcik kayit icin yukaridaki ozet gectigim optimizasyonlardan hic birini dusunmeye bile degmez (index dahil). Bugun, indexli bile olmasa, 500,000 kayitta bile bana performans endisesi yaratacak veritabanini makinemden iceri sokmam. Resimlerden goruldugu kadariyla senin veritabanin SQL Server. SQL Server bunu kendisine hakaret olarak algilar. Tabii yukarida index olmasa bile darken, en kotu senaryoda, full "table scan" yapilmasi gerekse bile demek istedim, yoksa "index" databaseler icin olmazsa olmazlardan gibi (bazen olmadiginda daha hizli ama onlar ileri duzey konular).

    Lafi uzatmayalim, senin icin yapi soyle olmaliydi (seninkinin uzerinden gidiyorum, ben boyle yapardim diye degil - database tasarim oyle bir gunde karar verebildigim bir sey olmadi asla):

    Kategoriler: KategoriID, KategoriAdi, ...
    BuNeIse: tabloAdiID, KategoriID, ... (yukaridaki tablonun yapisi sakat gorunuyor ama tabii amacinin vs sen biliyorsun)

    Bu yapi 1-To-Many. Yani bir kategorinin altinda bir suru senin "satir"larin.

    Bu Blog olsaydi mesela, o zaman zaten kategori (ya da cok bilinen sekliyle tag) her giris icin N tane olurdu. Yani bir blog girdisi (C#, ASP.Net MVC, ...) gibi bir cok kategoriye ait olabilirdi. O zaman yapi Many-To-Many. Iliskisel veritabani kullaniyorsan (ki SQL Server oyle):

    Kategoriler: KategoriID, KategoriAdi, ...
    BuNeIse: tabloAdiID,  ... (yukaridaki tablonun yapisi sakat gorunuyor ama tabii amacinin vs sen biliyorsun)
    KategoriTablo: tabloAdiID, KategoriID [, ...]

    seklinde (yani 3. bir tablo iki tablodaki ID'ler uzerinden birlestirmekte kullaniliyor). Bir ornek vermek gerekirse universitede ders alan ogrencileri dusun. Bir ogrenci N degisik ders alabilir ve herhangi bir dersin M degisik ogrencisi olabilir.

    Ogrenci: OgrenciID, Adi, Soyadi, ...
    Ders: DersID, Adi, ...
    OgrenciDers: OgrenciID, DersID, ...

    Ogrenciler:
    1, Ali, Veli
    2, Huseyin, Sari
    3, Cetin, Tembel

    Dersler:
    1, Matematik
    2, Kimya
    3, Fizik

    OgrenciDers:
    1, 1
    1, 2
    2, 2
    2, 3

    (Ali [Matematik, Kimya], Huseyin [Kimya, Fizik] dersleri aliyor. Cetin tembel almiyor, hic birini)

    (Matematik ogrencileri [Ali], Kimya [Ali, Huseyin], Fizik [Huseyin])

    • Yanıt Olarak İşaretleyen Serdar ALKA 16 Ekim 2014 Perşembe 14:50
    16 Ekim 2014 Perşembe 10:50

Tüm Yanıtlar

  • İlk olarak sen kesinlikle Önay hocanın dediğini yap. Verdiğin linki göz ucuyla inceledim orda kastı veritabanında tek bir tabloda herşeyi tutmak yani sadece kategori mantığı değil. Senin kategori diye bir tablon olucak burada sadece kategori adların ve birbirleri ile alt üst ilişki durumları bulunucak yani senin 100 ana kategorin olsun her birininde 5 alt kategorisi olsun 100 * 5 = 500 satır veri olucak. Sonra kuracağın yapıya bağlı olarak her ürünün kategori kolonuna Kategori tablosunda ki id yi yazıcaksın. Bu şekilde istediğin zaman kategori id si 1 olan ürünleri getir diyebilirsin.

    Performans olarak ele alırsak performansı tek etkileyen satır sayısı değildir ve senin bahsettiğin 3k-5k satır veri değil. Senin sunucunun ram-cpu olayı, sunucunun bulunduğu lokasyon, dağıtık bir mimari söz konusu mu, search işlemleri için kullandığın özel bir yöntem var mı(azure search), index olayların nasıl, kurduğun sql sorgusu nasıl yani o kadar çok şey etkiliyor ki.

    Son olarak tek tablo demişsin ve bazen tek tablo bazı veritabanlarında inanılmaz hızlı olur ki RDMS(SQL Server, Oracle) yapıları hız konusunda yanına yaklaşamaz. Bunun kullanımlarıda NoSQL veritabanlarında mevcut. Tabi neyi ne zaman nasıl kullanacağın önemli. Özetle kuracağın sistemin analizini iyi yapmış olman gerekiyor.

    Not: Orada yazdığın sql sorgusuna baktımda amacını hiç anlamadım. Bu şekilde ki bi sorgu ile ne yaparsan yap hız konusunu unutman lazım. 

    Not2: Hiçbir zaman kullanıcıya bütün verileri getiremezsin bunun içinde paging olayını yapman lazım yani her seferinde 20(?) kayıt getirecek(0-20,21-40,41-60). UX olayını göz ardı etmemek gerekiyor yoksa boşuna trafik artar ve kullanıcı memnuniyeti olmaz.

    • Yanıt Olarak Öneren CetinBasoz 16 Ekim 2014 Perşembe 10:06
    • Düzenleyen Berdann 16 Ekim 2014 Perşembe 10:26
    16 Ekim 2014 Perşembe 09:40
  • Önay hakli.

    Oncelikle verdigin linkten baslarsak, ne yazik ki internette yazilan her sey dogru degil. Cok aciklayici olmus ama yanlis olmus, konuyu yuzeysel dusunen, veritabanlarini bilmeyen kisileri inandirir. Arkadasa basitce sormak lazim, ev ilanlari icinden tek odali olanlar icin de ayri tablo tutsak daha hizli olmaz mi diye, sonra biraz daha parcalayalim, giris kati, teras, ..., semtler icin ayri tablolar. Kisacasi her kolon icin ayri bir tablo tutalim, hiza bak (mi). Veritabanlarinda hiz o sekilde saglanmaz. Hiz icin temel olarak kullanilan indexler var. E peki dosyalarin fiziksel boyunun hic mi onemi yok? Tabii ki var, ancak databaseler de bunu dusunuyor. Sana gore tek tablo gibi gorunen bir tabloyu yatay ya da dikey parcalara ayiriyorsun (bu databasede ince ayar kismi. Database adminlerin dusunmesi gereken seyler). Bir baska yontem o "tek tablo"yu cok sayida makineye dagitmak. Arkadasin dedigi gibi fiziksel dosyanin tamaminda degil sadece icinde bulundugu fiziksel dosyada araniyor. Kullanilan database cesidine gore yontemler cok farkli. Arastirmak istersen genelde bu konuyla ilgili terimler index, indexed partition, indexed view, partitioning, sharding, distributed transaction, column store, hstore, btree, fractal tree, ... diye gider.

    Senin rakamlarin uzerinden gidersek, en az 3000 satir 5000 olsun diyelim, 70 kategori de 100 olsun. Tablonda 100 * 5000 = 500,000 kayit olur. Bu kadarcik kayit icin yukaridaki ozet gectigim optimizasyonlardan hic birini dusunmeye bile degmez (index dahil). Bugun, indexli bile olmasa, 500,000 kayitta bile bana performans endisesi yaratacak veritabanini makinemden iceri sokmam. Resimlerden goruldugu kadariyla senin veritabanin SQL Server. SQL Server bunu kendisine hakaret olarak algilar. Tabii yukarida index olmasa bile darken, en kotu senaryoda, full "table scan" yapilmasi gerekse bile demek istedim, yoksa "index" databaseler icin olmazsa olmazlardan gibi (bazen olmadiginda daha hizli ama onlar ileri duzey konular).

    Lafi uzatmayalim, senin icin yapi soyle olmaliydi (seninkinin uzerinden gidiyorum, ben boyle yapardim diye degil - database tasarim oyle bir gunde karar verebildigim bir sey olmadi asla):

    Kategoriler: KategoriID, KategoriAdi, ...
    BuNeIse: tabloAdiID, KategoriID, ... (yukaridaki tablonun yapisi sakat gorunuyor ama tabii amacinin vs sen biliyorsun)

    Bu yapi 1-To-Many. Yani bir kategorinin altinda bir suru senin "satir"larin.

    Bu Blog olsaydi mesela, o zaman zaten kategori (ya da cok bilinen sekliyle tag) her giris icin N tane olurdu. Yani bir blog girdisi (C#, ASP.Net MVC, ...) gibi bir cok kategoriye ait olabilirdi. O zaman yapi Many-To-Many. Iliskisel veritabani kullaniyorsan (ki SQL Server oyle):

    Kategoriler: KategoriID, KategoriAdi, ...
    BuNeIse: tabloAdiID,  ... (yukaridaki tablonun yapisi sakat gorunuyor ama tabii amacinin vs sen biliyorsun)
    KategoriTablo: tabloAdiID, KategoriID [, ...]

    seklinde (yani 3. bir tablo iki tablodaki ID'ler uzerinden birlestirmekte kullaniliyor). Bir ornek vermek gerekirse universitede ders alan ogrencileri dusun. Bir ogrenci N degisik ders alabilir ve herhangi bir dersin M degisik ogrencisi olabilir.

    Ogrenci: OgrenciID, Adi, Soyadi, ...
    Ders: DersID, Adi, ...
    OgrenciDers: OgrenciID, DersID, ...

    Ogrenciler:
    1, Ali, Veli
    2, Huseyin, Sari
    3, Cetin, Tembel

    Dersler:
    1, Matematik
    2, Kimya
    3, Fizik

    OgrenciDers:
    1, 1
    1, 2
    2, 2
    2, 3

    (Ali [Matematik, Kimya], Huseyin [Kimya, Fizik] dersleri aliyor. Cetin tembel almiyor, hic birini)

    (Matematik ogrencileri [Ali], Kimya [Ali, Huseyin], Fizik [Huseyin])

    • Yanıt Olarak İşaretleyen Serdar ALKA 16 Ekim 2014 Perşembe 14:50
    16 Ekim 2014 Perşembe 10:50
  • Hocam öncelikle verdiğiniz ayrıntılı cevaplar için minnettarım bu kadar uğraşıp beni ve arkadaşları bilgilendirdiğiniz için gerçekten teşekkür etsem azdır :)

    O zaman dediğiniz gibi ben 2 tablo yapacağım Kategoriler ve KullaniciID

    Kategoriler Tablosunda ; KategoriID, KategoriAdi, AltKategoriAdi, Baslik, Icerik, Yorumlar, BegeniSayisi vs.. böyle böyle 15 ile 25 arasında sütun olacak :)

    Kullanıcılar Tablosunda ise ; KullaniciID,KullaniciAdi,Sifre vs.. diye 5-10 arası sütun olacak

    Başkada tablom olmayacak kategoriler tablosunda ilk etapta 1000 ile 3000 arasında verim olacak yıllarca giderek artacak satırlar...

    Aynı şekilde kullanıcılarda öyle 100 kullanıcım varsa 100 satırım olacak

    ŞİMDİ DOĞRUMU ANLAMIŞIM HOCAM ?

    Birde Berdann hocam sql sorgumu anlamamış ne yapmak istediğimi sorgum şöyleydi :

    select * FROM Bilgisayar UNION ALL select * FROM GuvenlikSistemleri UNION ALL select * FROM EvElektronigi) t1 INNER JOIN Kullanicilar ON t1.KullaniciID = Kullanicilar.ID Order By Tarih Desc

    Union all ile fazlalık olarak açtığımı anladığım tablolarımı birleştiriyorumdum.Yani bilgisayar,güvenliksistemleri,evelekrogini tablolarını alt alta birleştiriyor.SONRA İnner join ile kullanicilar tablosuna bağlanıp kullanicilar tablosundaki KullaniciID kisminida bu üç tabloya SÜTÜN olarak ekliyor.En son bu 3 kategori tablomu son yazılan mesaja göre (yani desc ile tersten) listeliyor.Böylelikle bana bu sorgu şunu yapıyor (şuan çalışır şekilde kulllanıyorum:) ) = her tablodaki satırlarları tek bir ekranda listeliyor ama yan yana değil alt alta listeliyor böylelikle her bir tablodaki satırı aynı ekranda görebiliyorum.Ayrıca KullaniciID ilede hangi konunun hangi kullaniciya ait olduğunuda görebiliyorum.Kullanicisi olmayan kayıtlar listelenmiyor.

    İşte bu söylediğiniz benim içinde iyi oldu.Çünkü mesela 10 tablom olsaydı bu onunuda birleştirmek zorunda kaldığım zamanlar oluyor UNION ALL diye diye 10 tane union all ard arda yazmak zorunda kalacaktım :).Şimdi ise select * from kategori where id= vs idye göre çekeceğim veriyi ohhh kafam rahat olacak :D

    16 Ekim 2014 Perşembe 15:11
  • Şimdi düşündümde bişi daha aklıma geldi adamlar konulara yorumda yapacaklar bu sefer üçüncü bir tablo daha yapmam gerekiyor sanırım yorum kategorisi ? sonra bu yorumlar kategorisini kategoriler tablosundan ID ile ilişkilendiririm.Yorumlar kategorisinde yorum yaptıkça satır satır ekler örnek vereyim

    Yorum Tablosu - KonuID

    teşekkürler      - 3

    asdasdasdas    - 4

    asdasdasdas    - 3

    böyle böyle gider sonrada konuIDye göre çekiyor zaten içeriği oradan KonuID = 3 olanları mesela çeker işte :D

    Ya inşallah amatörce düşünmüyorumdur :D yorum yaparsanız sevinirim :D

    16 Ekim 2014 Perşembe 15:37
  • Valla dogru anlayip anlamadigindan emin degilim. Sen galiba bir blog yapisindan bahsediyorsun, ondan da emin degilim.

    En iyisi sen once, Database Normalization konusunu en azindan 3.normal form dahil incele, SQL Server'in Northwind ornek databaseini indir ve onunla oyna biraz. Iliskisel veritabanlariyla ugrasacak isen normalizasyonu bilmen lazim. NoSQL serisi bir veritabanindan bahsediyor olsaydin o zaman cok daha kolay olabilirdi bir Blog-Post ornegi.

    Entity Framework, Code first kullanirsan isler senin icin daha kolay olabilir. Hatta EF6 ornegi galiba Blog-Post seklindeydi. Sen data modelini yaratiyorsun, EF sana database yaratiyor. Cok mukemmel bir yapi olmasa da seninkinden iyi kanimca, sonra ince ayar yapmasi daha kolay.

    Sanirim ben bu ornegi daha once postalamistim:

    void Main()
    {
        
        CreateSampleCodeFirstData();
        ShowData("First Time - Created Db (if not existed) and Inserted");
    	  UpdateData();
        ShowData("After updated");
        
    }
    
    
    private void UpdateData()
    {
        int id=2;
        var db = new BlogContext();
        var value = db.Bloglar.SingleOrDefault(c => c.BlogId == id);
        if (value != null)
        {
            value.Name = "Updated Name";
            value.Type = "Updated Text";
            db.SaveChanges();
        }
    }
    
    private void CreateSampleCodeFirstData()
    {
     	var ctx = new BlogContext();
    	var blog1 = new Blog { Name="Ilk deneme", Type="Basit - No posts"};
    	var blog2 = new Blog { Name="EF6", Type="Egitim",
    		Posts= new List<Post>() {
    			new Post { Baslik="b1", Etiketler="SQL", Makale="M1"},
    			new Post { Baslik="b2", Etiketler="EF, Linq", Makale="M2"},
    			new Post { Baslik="b3", Etiketler="Linq", Makale="M3"},
    	  }
    	};
    	var blog3 = new Blog { Name="Blog3", Type="Test",
    		Posts= new List<Post>() {
    			new Post { Baslik="b31", Etiketler="XX", Makale="M31"},
    			new Post { Baslik="b32", Etiketler="YY", Makale="M32"},
    	  }
    	};
    	
    	ctx.Bloglar.AddRange( new Blog[] {blog1,blog2,blog3} );
    	
    	ctx.SaveChanges();
    }
    
    private void ShowData(string title="")
    {
      if (!string.IsNullOrEmpty(title))
      {
        Console.WriteLine (title);
        Console.WriteLine ("".PadRight(title.Length,'='));
      }
      var ctx = new BlogContext();
      foreach (var b in ctx.Bloglar)
      {
        Console.WriteLine ("Blog Id:{0}, Name:{1,-50}, Type:{2}", 
          b.BlogId, b.Name, b.Type);
        foreach (var p in b.Posts)
        {
          Console.WriteLine ("\t\tPost Id:{0}, Baslik:{1},\tEtiketler:{2,-50}, Makale:{3}", 
          p.PostId, p.Baslik, p.Etiketler, p.Makale);
        }  
      }  
      Console.WriteLine ();
    }
    
    
    public class Blog
    {
      public int BlogId { get; set; }
      public string Name { get; set; }
      public string Type { get; set; }
    
      public virtual List<Post> Posts { get; set; }
    }
    
    public class Post
    {
      public int PostId { get; set; }
      public string Baslik { get; set; }
      public string Makale { get; set; }
      public string Etiketler { get; set; }
    
      public virtual Blog Blog { get; set; }
    }
    
    public class BlogContext : DbContext
    {
      public DbSet<Blog> Bloglar { get; set; }
      public DbSet<Post> Posts { get; set; }
    }

    16 Ekim 2014 Perşembe 17:49
  • Ya hocam lütfen bana basitçe anlatın :D şuan kafam o kadar basmıyor kod biliyor olabilirim ama yapıları bilmiyorum

    medium bir programcıyım daha :D med-high arasi gidip geliyorum.Bir anda zorlaştırınca kafam basmıyor :D

    Ya çok mühim değil şuan benim veritabanımın professionel bir tasarımının olması yani doğru yolda olayım yeter

    Nasolsa ilerde sorun yaşarsam ilerletirim veritabanını olmadı siler baştan yaparım :D.Yani sonuçta website yapması daha zor bence veritabanı işte tablolar oluşsun alanlar vs allah bereket versin.

    Şimdi ben 3 tane tablom olsun kategoriler yorum ve kullanici tablolari diye bunlar yeter sanırım demi?

    ŞUAN SORMAK İSTEDİĞİM ŞUDUR : Yorumları kategoriler tablosunda yazabilirmiyim? yani yazamam sanırım yorum1 yorum2 yorum3 diye sütunlar oluşturamam doğal olarak yeni bir tablo olacak (YANİ MECBURİ)

    16 Ekim 2014 Perşembe 18:21
  • Ya hala sen daha sorunu dogru duzgun soramadin. Ne tablolariyla ugrastigindan, ne saklamak istediginden bahsetmedin. Tutturmussun bir kategori, yorum, begeni ... gidiyor. Bunlar nedir, neye yarar sen biliyorsun ama ben bilmiyorum.

    Web site yapmasi daha zor diye dusunuyorsan medium oldugun konusunda hic emin olma.

    16 Ekim 2014 Perşembe 19:34
  • Ya hala sen daha sorunu dogru duzgun soramadin. Ne tablolariyla ugrastigindan, ne saklamak istediginden bahsetmedin. Tutturmussun bir kategori, yorum, begeni ... gidiyor. Bunlar nedir, neye yarar sen biliyorsun ama ben bilmiyorum.

    Web site yapmasi daha zor diye dusunuyorsan medium oldugun konusunda hic emin olma.

    Blog + Forum + Soru Cevap sitesi ben yararlı olacağını düşündüğüm yazılarımı paylaşacağım onlarda soru soracak tıpkı bu microsoftu sitesi gibi ama tek bir konuda değil örneğin bilgisayar veya yazılım ile ilgili değil her konuda yani forum mantığında olacak resminide atayım.Kategori yorum begeni felan diyorum işte bence yeter bu kadar :D sonuçta yorum yapacak beğeni sayısını görecek.Mantık bu :D Hocam biraz sinirlendirmişim sizi kusura bakmayın hakkınız helal edin :)


    16 Ekim 2014 Perşembe 19:43
  • Ya hocam lütfen bana basitçe anlatın :D şuan kafam o kadar basmıyor kod biliyor olabilirim ama yapıları bilmiyorum

    medium bir programcıyım daha :D med-high arasi gidip geliyorum.Bir anda zorlaştırınca kafam basmıyor :D

    Ya çok mühim değil şuan benim veritabanımın professionel bir tasarımının olması yani doğru yolda olayım yeter

    Nasolsa ilerde sorun yaşarsam ilerletirim veritabanını olmadı siler baştan yaparım :D.Yani sonuçta website yapması daha zor bence veritabanı işte tablolar oluşsun alanlar vs allah bereket versin.

    Şimdi ben 3 tane tablom olsun kategoriler yorum ve kullanici tablolari diye bunlar yeter sanırım demi?

    ŞUAN SORMAK İSTEDİĞİM ŞUDUR : Yorumları kategoriler tablosunda yazabilirmiyim? yani yazamam sanırım yorum1 yorum2 yorum3 diye sütunlar oluşturamam doğal olarak yeni bir tablo olacak (YANİ MECBURİ)

    med-high ? neye göre ? daha veri tabanı normalizasyon işlemleri bilmeyen birine göre iyi atmıyor musun?  Bence en zor kısımlarından biri veritabanı kısımlarıdır. Çünkü verdiğin kararı yaptığın proje kullanılmaya başlandıktan sonra değiştirmen zorlaşır yani verikaybı olsun o an için sistemin devre dışı bırakmak olsun daha büyük etkileri vardır. Web tarafında ise front-end ve back-end tarafını değerlendircek olursak. Fron-end tarafını kafana göre değişitir istediğini yap sonra direk yayınla yani kullanıcıyı etkileyen birşey yok. Back-end tarafıda aynı sen kendin lokalinde testini yaparsın sonra da bir gece atarsın hatta ilk önce test domaine publish eder orta test edip canlı ya alırsın.

    Buyur sana bir blog projesi. Design pattern lara uyularak yazılmaya çalışılmış. Kategori(Tag olarak değerlendirilmiş orada), Yorum ilişkiside var

    Not: Çetin Hoca'nın verdiği kod örneğine baktımda blog'u vermeme gerek yokmuş yani mantık aynısı!

    Not2: Birde burası gözüme çarptı sadece designlar mı ortak ;)

    • Düzenleyen Berdann 16 Ekim 2014 Perşembe 20:31
    16 Ekim 2014 Perşembe 20:22
  • Sen medium - high arasi gidip geliyorum diyorsun ama sana verdigim cozumu anlayamamissin. Oysa o cozum giris seviyesi.

    Sana diyorum ki, tablo yapilarinla ugrasma, ihtiyacini class'lari kullanarak model olarak belirle. EF6'yi devreye sokarak data ekle o sana tablolari yaratsin. Onlari inceleyip, duzenlersin. Yukarida bu isi sana Blog-Post ile yapan kodu da hazir verdim.

    Ben databaseleri bilmeyeyim, zor olan UI diyorsan sen nirvanaya ermissin, bana on numara buyuksun.

    17 Ekim 2014 Cuma 07:47

  • Sana diyorum ki, tablo yapilarinla ugrasma, ihtiyacini class'lari kullanarak model olarak belirle. EF6'yi devreye sokarak data ekle o sana tablolari yaratsin. 

    Hocam, bunu anlatmak o kadar zor ki. Oğuz, Soner , Berdan haricinde anlayabileni görmedim daha. 

    www.mvcblog.org
    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com

    17 Ekim 2014 Cuma 08:21
    Moderatör
  • Teşekkür ederim sayın önay,oğuz,soner,berdan hocalarım.Yani şimdi bir yanda benim gibi kas kafalı biri :) İşte EF6 ne demek class'ı kullanarak modeli ekle ne demek vs vs bilmediğim için zor geldi bana.Şuan yeni birçok şey öğrendim dediklerini araştırarak inşallah ilerletirimde en azından anlıyacak kıvama gelirim :).Şimdilik veritabanını askıya aldım.Siteyi geliştirmeye devam ediyorum.Ama bilgileriniz sayesinde büyük bir değişikliğe uğrattım veritabanımı ve güzel bir şekilde çalışır hale geldi (Öncekine nazaran)
    17 Ekim 2014 Cuma 11:53