Veritabanında verilerin tutulma şekliyle ilgili emin olamadığım bi kaç nokta var...
Örneğin Stok Hareketlerinin işlendiği bir tablo var, Burada "Ürünler" tablosundan gelen ürünün ismini Stok Hareketlerin işlendiği tabloya yazdırmak ne kadar mantıklı? sadece Ürün kodunu işlemek sonradan yazılabilecek sorguları zora sokar mı?
Dahası, bir şirket otomasyonu için her tür cari hesap hareketi(personel, kredili hesap müşterileri, tedarikçiler v.s.) ve stok hareketlerini (alış/satış) bir tabloda tutmak mantık lımı... Tablodaki alan sayısını artırarak bunu yapmak mümkün gibi gözüküyor (Yaklaşık 60 Alan) Şöyleki;
- Kişiler/Kurumlar (Müşteri, Personel, Tedarikçi, Yetkili vs.) - Ürünler/Hizmetler (Hertürlü alınan/satılan ürün hizmetler) - Gider Grupları (Kategorisine Göre Kullanıcı tarafından oluşturan Gider Çeşitleri) - Bankalar (Yine Kullanıcının Tanımlayacağı Bankalar) vs...
gibi bütün hareketlerin tutulacağı tablodaki hareket kimliğini tamamlayacak alanlar ayrı tablolarda ve bütün bunlardan bilgi alan ve bütün cari hesap hareketlerinin işlendiği tek bir tabloya bağlayarak çalışmak ne kadar başarılı olur sizce?
Yoksa örneğin ürün(alış/satış) hareketlerini, cari hesaplardaki tutar hareketlerinden ayırmak mı gerekir...??
< Bu mesaj bu kişi tarafından değiştirildi SiyahPelerinliAdam -- 20 Eylül 2008; 4:13:30 >
_____________________________
"...Tutkularını haklı çıkarmak adına aklını küçük düşürmektense, Tutkularına bile bile boyun eğmek yeğdir..."
Veritabanı tasarlarken 2 tür tablo yapılır : 1- Lookup 2- Fact
Lookup tabloları, birden fazla kullanılan değerleri tutmak icin kullanılır. Örneğin; il tablosu. ilçe tablosu, Ürün tablosu
Fact tabloları ise esas verinin bulunduğu tablolardır. Örneğin; fatura tablosu. Yada ürün tablosu.
Fact tablosunu su sekilde düşünelim. FATURA_ID,TARIH,ALICI_ADI,ADRES,IL_ID
Bir de tüm illeri tutmak için il tablomuz olsun. IL_ID,IL_ADI 06 ANKARA 34 İSTANBUL . . .
Bu şekilde yarattığımız fact tabloda IL_ID kısmına İstanbul için '34' yazmamız yeterli. Kullanacağınız sorgularda da bu iki tabloyu join etmeniz yeterli. Eğer lookup kullanmadan direk il ismini yazsaydık her istanbul adresi için 2 karakterlik alan yerine 8 karakterlik alan ayırmak zorunda kalacaktık. Bu da gereksiz yere disk kapasitesini yükseltecekti.
Cevaplar için gerçekten çok teşekkürler, bundan sonra ne şekilde yönlenmem gerektiği ile ilgili ciddi fikirler verdi.
Ancak programcı bir arkadaş ile çok netleştiremediğimiz bir mevzu da fact( bilgi için tşk :) ) tablolarını mümkün olduğunca azaltmanın bir faydası olur mu? Örneğin ürün stok hareketleri ile cari hesap & çek senet hareketlerinin aynı tabloda toplanmış olması bir avantaj sağlar mı... Alan sayısını artırarak ve alanları akıllıca kullanarak bunu yapmamız mümkün gibi gözüküyor ancak bunun gerekli olduğundan emin değilim.
_____________________________
"...Tutkularını haklı çıkarmak adına aklını küçük düşürmektense, Tutkularına bile bile boyun eğmek yeğdir..."
Cevaplar için gerçekten çok teşekkürler, bundan sonra ne şekilde yönlenmem gerektiği ile ilgili ciddi fikirler verdi.
Ancak programcı bir arkadaş ile çok netleştiremediğimiz bir mevzu da fact( bilgi için tşk :) ) tablolarını mümkün olduğunca azaltmanın bir faydası olur mu? Örneğin ürün stok hareketleri ile cari hesap & çek senet hareketlerinin aynı tabloda toplanmış olması bir avantaj sağlar mı... Alan sayısını artırarak ve alanları akıllıca kullanarak bunu yapmamız mümkün gibi gözüküyor ancak bunun gerekli olduğundan emin değilim.
Fact tabloların fazla olması, tek bir tabloya tüm alanların yazılmasından daha iyidir. Örneğin; Bir fatura düşünün. Bu faturada 3 ürün alınmış. Toplam 300 ytl. Ve fatura nakit(200 ytl) ve kredi kartı (100 ytl) olarak ödenmiş. Şimdi bu bilgiyi tek bir tabloya nasıl yazarız ?
Her ürün için Fiş Kodu (yada Sepet Kodu) ve Fiş Tutarı (yada Sepet Tutarı) gibi alanlar gerekliki bunlar sepet içerisindeki her üründe tekrarlanmış olucak ve bu da tekrarlanmış gereksiz veri anlamına gelicek...
Bu tekrarlanmanın her fatura/fiş için farklı tablo da oluşacak bir satırdan daha verimli olabileceği ihtimali bu soruya sebep olmuştu aslında :)
Cevaplar için çok çok teşekkürler...
_____________________________
"...Tutkularını haklı çıkarmak adına aklını küçük düşürmektense, Tutkularına bile bile boyun eğmek yeğdir..."
Her ürün için Fiş Kodu (yada Sepet Kodu) ve Fiş Tutarı (yada Sepet Tutarı) gibi alanlar gerekliki bunlar sepet içerisindeki her üründe tekrarlanmış olucak ve bu da tekrarlanmış gereksiz veri anlamına gelicek...
Bu tekrarlanmanın her fatura/fiş için farklı tablo da oluşacak bir satırdan daha verimli olabileceği ihtimali bu soruya sebep olmuştu aslında :)
Cevaplar için çok çok teşekkürler...
Aklın yolu bir :)
FATURA ( fatura_id,tarih_id,magaza_id,kasiyer_id,fatura_toplam_tutar) = 1 kayıt . sadece fatura bilgisi FATURA_DETAY (fatura_id,urun_id,urun_tutar,urun_adet) = 3 kayıt. her bir ürün için detay FATURA_ODEME (fatura_id,odeme_turu_id,odeme_tutar) = 2 kayıt. her bir ödeme türü için birer kayıt.
odeme_turu_id alanı icin ODEME_TURU tablosuna join. urun_id için URUN tablosuna join.
Bütün yazılan ticari uygulamalar farklı modüller içerecekse ilişkisel veritabanını tercih eder. Yani modül derken ticari bir proje hangi modülleri içerebilir.
Sipariş üretim satış depolama sevkiyat vs.
Bunları ayrı tablolarda kullanmak uygulamanızın geleceği ve revize edilebilirliğinide arttıracaktır. Ayrıca bütün datayı tek tabloya tıkmaya çalışmak hem sizi kod yönüyle yoracak ve revizeye karşı tehlikeli bir yapı oluşmasına neden olacaktır. Database içerisinde mesela Oracle içerisinde bir tablo içerisine engine tarafından kayıt yazılmadığı sürece hiç bir alan kaplamaz (index ve tabloyla ilgili sistem özelliklerinin kapladığı küçük alanı saymazsak.) .
Önceki postta ki arkadaşımızın tarif ettiği gibi ilişkisel raporları SQL ile rahatlıkla alabilirsiniz artı olarak yazma işlemi normal tek tablodan rahat ve düzenli olacaktır. Ama mimariyi iyi kurmalısınız.
Aslında projede bizi zora sokan da şirketin kurumsal yapısı... Girilen herhangi bir data işletmedeki bir çok birimle ilişkili... Üretim ve de satış yapan 3 ayrı birim olduğu gibi her birimin kendi tedarikçisi yahut müşterisi farklı koşullarda işlem görebiliyor... Kötüsü pratikte şirketin kasası tek... :)
Verdiğiniz fikirler ve bilgiler için gerçekten teşekkürler, ileriye dönük mimaride düşme ihtimalimin bulunduğu bir takım yanlışlardan sayeniz de geri durduğumu sanıyorum.
Tekrar teşekkürler...
< Bu mesaj bu kişi tarafından değiştirildi SiyahPelerinliAdam -- 7 Ekim 2008; 2:50:46 >
_____________________________
"...Tutkularını haklı çıkarmak adına aklını küçük düşürmektense, Tutkularına bile bile boyun eğmek yeğdir..."
Basılabilir versiyon
Tüm forumlar >> [Web Tasarım - Programlama] >> Yazılım Geliştirme >> MsSQL / MySQL >> Veritabanı Tablo Oluşturma Mantığı? 
20 Eylül 2008; 4:12:56
Yeni mesajlar
Yeni mesajlar yok
Popüler konu, yeni mesajlar ile
Popüler konu, yeni mesajlarsız
Kilitli yeni mesajlar ile
Yeni mesajlar olmadan kilitli
Yeni mesaj at
Mesajımı DH blog sayfama ekle
