Konuyu Oyla:
  • Derecelendirme: 4/5 - 2 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Messenger için Tablo yapısı Doğrumu?
#1
Merhaba,
Firebird vt kullanıyorum, anlık mesaj gönderip alınması için hazırladığım arayüze ait tablo yapısı aşağıdaki şekilde.
Burada açıklamak istediğim alanlar;
GONDEREN_AKTIF ve ALICI_AKTIF alanlarını kullanıcının geçmişi sil dediği zaman 0 yaparak ekranda gözükmemesini sağlamak için eklediğim alanlardır. Gönderen görüşme geçmişi silmişdir fakat alıcı silmemiştir kontrolü için.
ALICI_OKUDU alanı ise ekrana gelen mesaj bilgisini vermek için oluşturduğum alandır.

Merak ettiğim Hususlar:
  1. Tablo yapısının olması gerektiği gibi tasarlanıp tasarlanmadığı!
  2. Tek bir tabloda tüm kullanıcılar için kayıtları tutmak doğru mudur? (kendi kullanıcı sayım çok az fakat genel değerlendirelim istiyorum )

Şimdiden teşekkürler ve iyi çalışmalar.

Ekran_Al_nt_s_2222.png
Cevapla
#2
Merhaba,
Veri tabanı Modelleme başlı başına bir ihtisas konusudur. 
Veri tabanı uygulamalarında projeye başlanmadan önce mutlaka bir analiz yapılmalıdır. 
Analiz sonucunda ihtiyaçlar ortaya çıkar ve daha sonra uygulama içerisinde ana ve alt modüller belirlenir. Bu durumda hangi modül/alt modülün veri tabanı bağlantısı ile çalışacağı tespiti yapılmalıdır. Projede veri tabanına bağlı olacak modülde geçen alanlar ve tipi tek tek belirlenmelidir. Belirlediğiniz alan adları ile veri tabanında kullanacağınız tablo adı ve tablo alan adları birbirlerini çağrıştırıcı olmalıdır. 
Örneğin Tablo adı: PERSONEL, bu tabloda geçen alan adlarından biri ADI_SOYADI olduğunu varsayalım. Projede iki adet Edit alanı olmalıdır. Bunların projede adı (Name) edtAdı ve edtSoyadı olmalıdır. Edit'lerin, Edit1 ve Edit2 şeklinde kullanılması durumunda ilerleyen süreçte projenin içinden çıkılmaz hale gelinecektir. Hangi nesne hangi bağlantıyı kullanıyor tespiti zorlaşacaktır.
1. Sorunuzun cevabı: Standart bir yol tutturmak zaman ve tecrübe istiyor. Veri tabanı tasarımınız kimine göre iyi, kimine göre eh, kimine göre de hiç olmamış olabilir. Bunu sormanız bana göre öğrenmeye ve eleştirilere açık olduğunuzu gösteriyor. İkinci sorunuzun da cevabını içeren ve ilk sorunuzun da kıyaslamasını kendinizin yapabileceği örnek bir Veri Tabanı modeli paylaşıyorum.


2uruo2v.jpg


İyi çalışmalar
Cevapla
#3
Selam,
Bence mantık olarak gayet doğru bir yaklaşım fakat alan tipleri konusunda şuna dikkat edin bence. İnteger tipi Veritabanında 4 byte alan kaplar ALICI_KODU, GONDEREN_AKTIF ve ALICI_AKTIF alanlarınızda sadece 0 ve 1 kullanacaksınız muhtemelen, o yüzden ben olsam o alanları "SmallInt" yaparım ki Veritabanında 2 Byte alan kaplasın, yada char(1) de yapabilirsiniz ama ben genelde bu tip işlerde rakamsal tip kullanırım ki sorgularda daha hızlı çalışsın.

... Bu arada Fesih bey ile pişti olduk sanırım.

Ek olarak Fesih beyin dediği şekilde projede kolaylıkla kod yazıp karıştırmamak için; GONDEREN_AKTIF, ALICI_AKTIF yerinede GONDEREN_SILDI, ALICI_SILDI gibi yapabilirsiniz. Zira ilerleyen zamanlarda bir değişiklik gerektiğinde bu neydi diye düşünmezsiniz.
WWW
Cevapla
#4
(31-08-2016, Saat: 12:11)Fesih ARSLAN Adlı Kullanıcıdan Alıntı: Bunu sormanız bana göre öğrenmeye ve eleştirilere açık olduğunuzu gösteriyor.


(31-08-2016, Saat: 12:16)esistem Adlı Kullanıcıdan Alıntı: Selam,
Bence mantık olarak gayet doğru bir yaklaşım fakat alan tipleri konusunda şuna dikkat edin bence. İnteger tipi Veritabanında 4 byte alan kaplar ALICI_KODU, GONDEREN_AKTIF ve ALICI_AKTIF alanlarınızda sadece 0 ve 1 kullanacaksınız muhtemelen, o yüzden ben olsam o alanları "SmallInt" yaparım ki Veritabanında 2 Byte alan kaplasın, yada char(1) de yapabilirsiniz ama ben genelde bu tip işlerde rakamsal tip kullanırım ki sorgularda daha hızlı çalışsın.

Öncelikle cevaplarınız için teşekkürler.
Evet hocam eleştiriye açığım ve doğru olanı öğrenmek istiyorum.
Belirtmiş olduğunuz konuları çok iyi anladığımı belirmek isterim. buradaki hatalı yaklaşımım hariç geri kalan kısım sanırım sizlerin de söylediği gibi göreceli bir yapıdan bahsediyoruz.
Merakım aslında piyasadaki kullanılan uygulamalar, örnek Wahtsapp tarzı uygulamaların VT yapısı, bana hep tek bir tabloda tutulmuyordur düşüncesi oluşturuyor(yanlış düşünüyor olabilirim). Kendi çapımda farklı senaryolar oluşturuyorum fakat istediğim cevap çıkmıyor bir türlü Smile
Cevapla
#5
(31-08-2016, Saat: 14:18)Cyber Adlı Kullanıcıdan Alıntı:  bana hep tek bir tabloda tutulmuyordur düşüncesi oluşturuyor


Tek bir tabloda tutmak, (milyonlarca insanın kaydı söz konusu olduğunda) benim de aklıma yatmıyor, bana kişiye özel tablolar daha mantıklı geliyor. her kişi için bir tablo birbirleriyle id'leriyle bağlı mesajlar. yeni üye kaydında açılan yeni tablo bana çok daha mantıklı geliyor.

Ben bir mesajlaşma uygulaması yazsaydım büyük ölçüde böyle yazardım.
Tek bir tablo bir sunucuda tutmak mümkün değil.  tabloları kişilere göre parçalayıp farklı sunuculara ayırırdım. bin kişi bir sunucuda diğer bir kişi diğer sunucuda gibi.

ama sen küçük çapta olacak diyorsun, bu şekilde bir yapının (tek tablo) bir problem yaratacağını düşünmüyorum.
WWW
Cevapla
#6
(31-08-2016, Saat: 09:19)yhackup Adlı Kullanıcıdan Alıntı: Bende Whatsapp düşünmüştüm. Skyp'da mantıklı, olmadı kendi uygulamamızı yazarız Smile

(31-08-2016, Saat: 14:34)yhackup Adlı Kullanıcıdan Alıntı:
(31-08-2016, Saat: 14:18)Cyber Adlı Kullanıcıdan Alıntı:  bana hep tek bir tabloda tutulmuyordur düşüncesi oluşturuyor


Tek bir tabloda tutmak, (milyonlarca insanın kaydı söz konusu olduğunda) benim de aklıma yatmıyor, bana kişiye özel tablolar daha mantıklı geliyor. her kişi için bir tablo birbirleriyle id'leriyle bağlı mesajlar. yeni üye kaydında açılan yeni tablo bana çok daha mantıklı geliyor.

Ben bir mesajlaşma uygulaması yazsaydım büyük ölçüde böyle yazardım.
Tek bir tablo bir sunucuda tutmak mümkün değil.  tabloları kişilere göre parçalayıp farklı sunuculara ayırırdım. bin kişi bir sunucuda diğer bir kişi diğer sunucuda gibi.

ama sen küçük çapta olacak diyorsun, bu şekilde bir yapının (tek tablo) bir problem yaratacağını düşünmüyorum.

Eğer kayıt sayınız zamanla milyonlara çıkarsa yakup beyin dediği gibi bir mantık mecburen kendiniz bulacaksınız zaten, büyük firmalarda sonuçta veritabanı kullanıyor, ama yük fazla olmasın diye mecburen ayrı serverlar ayrı veritabanları oluşturuyorlar. En basitinden milyonlarca kaydım olacaksa kaydolan kişinin adına göre tablo açarım olur biter. Misal KULLANICI_A, KULLANICI_B gibi A ile başlayanlar bir tabloya, B ile başlayanlar başka tabloya, 10 milyon kayıt tek bir tabloda olmasından sa bunu harf harf bölerim yükü azaltırım, her tabloyu farklı bir veritabanına oluşturup, her veritabanınıda farklı bir servera kurarsanız, tek serverdan sadece gelen ismin baş harfine göre yönlendirme yaparsınız olur biter.
WWW
Cevapla
#7
Bu defada şöyle bir durum ortaya çıkarmı?
KULLANICILAR tablosuna aşağıdaki şekilde kullanıcıyı ekledik.
ID=xx
USER=CYBER
USER_TABLO_ADI=KULLANICI_CYBER

mesajların tutulacağı tabloyuda KULLANICI_CYBER şeklinde oluşturduk!

Şimdi 2. kullanıcı USER_XXX, CYBER  kullanıcısına mesaj yolladığında yapı şu şekilde mi olacak?

kullanıcılar tablosunda kullanıcıyı arayacağız bulduğumuz kullanıcının tablo adını alıp bu tabloya gönderilecek mesajı işleyeceğiz.
Bu defa aynı şekilde kendi KULLANICI_XXX tablosuna da bu mesajı gönderdiğini bildireceğiz aksi taktide KULLANICI_CYBER tablosu silindiğinde tek taraflı mesaj içeriği kalacaktır.yada silinmediğini varsayarsak aynı mesaj 2 tabloya birden yazılmak zorunda kalacak.
çok ters bir açıdan(kulağı tersten tutarak) mı bakıyorum acaba konuya Huh

böyle bir yapıya ihtiyacım yok ilk mesajdaki yapı fazlası ile yetip artıyor ama merak ???

Araştırma yapmadan soru sorduğumu düşünmeyin en basitinden Forum özel mesaj tablo yapısına dahi baktım.
Cevapla
#8
Bana göre İlişkisel veri tabanı yönetim sistemlerinde (RDBMS) bu tip ince ayrıntılara hiçte gerek yok. Tablonun büyüklüğünden ziyade index yapısı daha çok önem taşıyor. 
6-7 Bin kullanıcılı, günlük 25-30 bin sorgunun yapıldığı, 30 dan fazla veri tabanından kayıt getiren (bu arada eş zamanlı sorgu sayısı 50-60) uygulamaların sıkıntısız çalıştığına bizzat şahit oldum. Yani tablo yapısından ziyade kullanılan veri tabanı, veri tabanı performans ayarları ve yönetimi (DBA) son derece önem taşımaktadır.
Örneğin, Oracle gibi bir veri tabanına yüksek çözünürlüklü (5 MB) tek seferde (her kayıtta) 100 resimi detay tabloya atarak (doğrudan BLOB alana) sorgular yaptım. Sonuç mükemmel. 
Tabi bu durumda Oracle ile diğer veri tabanlarını kıyaslamak biraz abes olur ama, bu tip (RDBMS) veri tabanları, sunucunun gücüne bağlı olarak olağanüstü performans sergilerler.
DBA olarak, yalnızca db Objeleri arasındaki ilişkileri doğru yapmak ve yönetimsel ayarları optimize etmek gerekiyor.
Cevapla
#9
Merhaba,
sanırım hocamızın da dediği gibi,
Alıntı:Standart bir yol tutturmak zaman ve tecrübe istiyor.

Yapıyı sağlam taşlar üzerine kuralım ki ileriye dönük olsun, iş yükü çıkartmasın. zamanla ihtiyaçlar doğrultusunda hareket edilecektir.
Teşekkürler cevaplarınız için.
Cevapla


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
Bug SQL e Bağlantıda Tablo Adını bir değişkene atamak barissagir 3 404 10-02-2024, Saat: 16:11
Son Yorum: barissagir
  Tanım Bulamadım Bu Hata İçin hi_selamlar 11 1.339 30-10-2023, Saat: 18:20
Son Yorum: hi_selamlar
  Yeni Bir Dil için Tavsiye KUNTAY 24 3.737 04-08-2023, Saat: 13:54
Son Yorum: Halil Han BADEM
  FastReport detail tablo gösterim sorunu Frrst 12 1.731 14-07-2023, Saat: 17:10
Son Yorum: hi_selamlar
  Tablo Dinleme barissagir 2 552 11-07-2023, Saat: 12:36
Son Yorum: delphiman



Konuyu Okuyanlar: 1 Ziyaretçi