Tüm Platformlar için Hızlı Uygulama Geliştirme Kitabı... Delphi

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 5/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Tablodaki field sayısı ne kadar önemli
#1
Personel bilgilerini bulunduracak tablomu tasarlama aşamasındayım. Saydığımda bu tabloya kaydedilmesi gereken 60 civarı alan olduğunu gördüm. Bana fazla geldi.
Ancak bu alanların tamamı bir kez kaydedilecek bilgiler, yani baba adı gibi, tek bir cevabı olan alanlar. Aldığı eğitimler, kurslar gibi değil.

Şimdi bu alan sayısı bana fazla geldiğinden kimlik bilgileri gibi alt tablolar oluşturayım diye düşündüm. Bu işlem ana tablonun field sayısını önemli ölçüde düşürür. Düşürür düşürmesine de,
bu defa veri girişi biraz zorlaşır. Örneklendirecek olursam, ilk önce ana tabloya personel kaydı yapılacak, bu kayıt tamamlanınca kimlik tablosu vb şekilde böldüğüm alt tablolara gidilip bu tablolara yeni kayıt eklenecek, bilgiler girilip kaydedilecek.

Ben kullanıcı dostu olmasını istediğimden, kullanıcının veri girişini zorlaştırmasına pek taraftar değilim. Ancak tablodaki alan sayının fazlalığı da beni içten içe rahatsız ettiğinden bir danışayım istedim.
Tablodaki alan sayısı ne kadar önemli? Sırf alan sayısını düşürmek için bazı veriler alt tablo şeklinde bölünmeli mi?
Cevapla
#2
Kullanıcı kolaylığı açısından tabloların ayrılmasının bir mahsuru yok. Siz kayıt esnasında önce ana tablo sonra alttablo yaparsınız. Kullanıcı bunu farketmez. Bağlantı için kullanacağınız ID bilgisini kayıttan hemen önce çağırın o bilgiyi hepsine işleyip kaydedin.
Ama tablo bölmekdeki esas amaç veri tekrarını engellemektir. Çok field olmasının bir mahsuru olduğunu bugüne kadar hiçbir yerde duymadım. Ama tabi böyle bir tabloda select * from tablo komutu kullanırken hassas olmak gerekir. Acaba 60 fielddın hepsine ihtiyaç var mı diye. Yoksa select musteri_kod from musteri dediğiniz zaman 60 field olmuş 160 field olmuş farketmez. Index'i musteri_kod 'a göre yapın yeter.
Topluluk mopluluk yok :/
Cevapla
#3
Alan sayısının fazla olmasının bir mahsuru yoksa, tabloyu bölmeme gerek yok o zaman.
Teşekkür ediyorum. (+rep)
Cevapla
#4
Merhaba,

Alan sayısının fazla olmasının sadece "teknik" olarak bir sakıncası yok. Ama bir tabloda 60 tane alan varsa bu tabloya veri girmek, bu tabloda veri güncellemek, sorgu çalıştırmak, arama yapmak, rapor hazırlamak, INSERT/UPDATE kodlarını yazmak hepsi inanılmaz zor olur. Bir kere insert kodunu bir seferde yazamazsınız Smile SP'lerde canınız çıkar. Onun yerine gruplayın verileri ve farklı tablolara bölüm. Basit bir örnek belki ama örneğin müşteri tablosunda kimlik bilgilerini (doğum yeri, cüzdan no, cilt no vs gibi bilgiler, yoksa adı/soyadı değil) tutmayın. Kimlik bilgilerini MusteriKimlik diye ikinci bir tabloda tutun. Her müşteri için boş da olsa MusteriKimlik tablosuna boş bir satır girin ve INNER JOIN ile bağlayın. Ya da kayıt girmeyin ve LEFT/RIGHT OUTER JOIN ile bağlayın. Bu şekilde yaptığınız zaman daha çok iş yapmış gibi olacaksınız, ama aslında çok daha hızlı iş yapacaksınız. Ayrıca şunu da unutmayın, kullanıcı bu verileri bir seferde giremez. En azından siz kullanıcıya içinde 60 tane Edit olan bir form göstermeyin Smile Bunları da alt pencerelere bölün. Hem veri kaybı riski minimuma iner, hem de kullanıcı pencereleri görünce "bu ne kadar karmaşık bir pencere" diye korkmaz.

Mikro veri tabanı ile ufak tefek işler yaptım, inanın etmediğim laf(!) kalmadı. Cari hesaplar tablosunda 175 tane field var. Kimse bana bu tablonun tasarımının doğru olduğunu iddia edemez. Bu buz gibi yanlış bir tasarımdır, veri tabanı tasarlamayı bilmeyen adamın tasarımıdır ve her türlü veri tabanı tasarlama kurallarına aykırıdır. Siz yolun başındayken bu hataya düşmeyin.

İyi çalışmalar
Cevapla
#5
Sizin yorumunuzu da okuduktan sonra yine tereddüte düştüm.

Benim için tek tablo olması daha kolay. Veri sorgularken tabloları bağlamaya vs. gerek kalmadan tek tablodan istediğim verileri çekebileceğim. Kayıt da sıkıntı değil çünkü updatesql nesnesininde desteği ile append, post kodlarını kullanacağım. Sorgularda sık kullanacağım alanlara index tanımlayacağım. Ek olarak kullanıcı açısından veri girişi de tek defada tamamlanacak.

Beni rahatsız eden konu field sayısı yüksek olduğundan, tabloya girilen veri sayıları arttıkça programın çalışmasına olumsuz etkileri olur mu? İleride baş ağrıtır mı?
Cevapla
#6
(28-03-2018, Saat: 16:27)canbir Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlSizin yorumunuzu da okuduktan sonra yine tereddüte düştüm.

Benim için tek tablo olması daha kolay. Veri sorgularken tabloları bağlamaya vs. gerek kalmadan tek tablodan istediğim verileri çekebileceğim. Kayıt da sıkıntı değil çünkü updatesql nesnesininde desteği ile append, post kodlarını kullanacağım. Sorgularda sık kullanacağım alanlara index tanımlayacağım. Ek olarak kullanıcı açısından veri girişi de tek defada tamamlanacak.

Beni rahatsız eden konu field sayısı yüksek olduğundan, tabloya girilen veri sayıları arttıkça programın çalışmasına olumsuz etkileri olur mu? İleride baş ağrıtır mı?

Evet, başınızı ağrıtır. Alan sayısı fazla ise, kayıt sayısı arttığında INSERT işlemi yavaşlar. UPDATESQL kullanacağım diyorsunuz, peki yazacağınız SP'lerde ne yapacaksınız? O SP'lerde uzun uzun fieldların hepsini yazmanız gerekecek. Hele bir de SP ile kayıt girdiğinizi düşünün, nasıl da zor olacak. Sadece yazması değil, sonradan okuması/değiştirmesi de çok zor olacak. 

İki tane JOIN yazmaya üşenmeyin veya bundan korkmayın. Türkiye'deki bir çok programcı çok ciddi bir hata yapıyor: "İşlerim kolaylaşsın" düşüncesiyle veri tabanına Foreign Key, NOT NULL, NULL, Check Constrain, Unique Key/Index vs tanımlamıyor. Örneğin NULL olması gereken alana 0 yazıyor (ki 0 NULL değildir). Eğer veri tabanı tasarım kurallarına uyacak olursanız inanın işler sandığınız kadar zor olmuyor. Bence burada unutulmaması gereken en önemli konu şu: Program yazmak hızlı yapılan bir iş değildir! Hızlı çözüm üretirseniz, gelecekte bunun bedelini çok daha ağır ödeme riskini de almış olursunuz. Bu önerme sizin için de geçerli. 

İyi çalışmalar
Cevapla
#7
(28-03-2018, Saat: 16:36)Bahadir.Alkac Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(28-03-2018, Saat: 16:27)canbir Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlSizin yorumunuzu da okuduktan sonra yine tereddüte düştüm.

Benim için tek tablo olması daha kolay. Veri sorgularken tabloları bağlamaya vs. gerek kalmadan tek tablodan istediğim verileri çekebileceğim. Kayıt da sıkıntı değil çünkü updatesql nesnesininde desteği ile append, post kodlarını kullanacağım. Sorgularda sık kullanacağım alanlara index tanımlayacağım. Ek olarak kullanıcı açısından veri girişi de tek defada tamamlanacak.

Beni rahatsız eden konu field sayısı yüksek olduğundan, tabloya girilen veri sayıları arttıkça programın çalışmasına olumsuz etkileri olur mu? İleride baş ağrıtır mı?

Evet, başınızı ağrıtır. Alan sayısı fazla ise, kayıt sayısı arttığında INSERT işlemi yavaşlar. UPDATESQL kullanacağım diyorsunuz, peki yazacağınız SP'lerde ne yapacaksınız? O SP'lerde uzun uzun fieldların hepsini yazmanız gerekecek. Hele bir de SP ile kayıt girdiğinizi düşünün, nasıl da zor olacak. Sadece yazması değil, sonradan okuması/değiştirmesi de çok zor olacak. 

İki tane JOIN yazmaya üşenmeyin veya bundan korkmayın. Türkiye'deki bir çok programcı çok ciddi bir hata yapıyor: "İşlerim kolaylaşsın" düşüncesiyle veri tabanına Foreign Key, NOT NULL, NULL, Check Constrain, Unique Key/Index vs tanımlamıyor. Örneğin NULL olması gereken alana 0 yazıyor (ki 0 NULL değildir). Eğer veri tabanı tasarım kurallarına uyacak olursanız inanın işler sandığınız kadar zor olmuyor. Bence burada unutulmaması gereken en önemli konu şu: Program yazmak hızlı yapılan bir iş değildir! Hızlı çözüm üretirseniz, gelecekte bunun bedelini çok daha ağır ödeme riskini de almış olursunuz. Bu önerme sizin için de geçerli. 

İyi çalışmalar

Field sayısının artmasıyla update/insert kod yazımlarının uzamasına katılıyorum. Ama ileride neden insert komutu yavaşlayacak onu anlamadım. Kaydın artması indexleme işlemini uzatır. Ama tablolara dağıtsanızda herbirinde ayrı ayrı index  gerekir yavaşlayacaksa yine yavaşlar. Ki 60 kaydın uzunlukları veri tipleri vs. de önemli. Evet göze güzel gözükmüyor ama bildiğim kadarıyla kayıt tekrarı olmadan tablo bölümlemek bir optimizasyon yöntemi değil.
Topluluk mopluluk yok :/
Cevapla
#8
bahadır bey cevap yazıyor görüyorum, daha da detaylandırır ama kısadan yazayım;

Şimdi yazacaklarım madalyonun sadece (1) yüzü. Ağ performansını göz ardı ederek trafiğin sadece veritabanının olduğu sunucuda işlem yaptığını varsayarak yazıyorum.

1 Tabloda 100 field için 1 SELECT sorgusu ile sadece ilgilendiğiniz (5) tane field seçerseniz, bu tablo okuma hızını 100 field'in tümünü SELECT * FROM ile almaktan çok daha hızlıdır. Hatta WHERE ile başlayan eleme işlemlerinizde şartsız net eleme filtreleri kurarsanız o zaman daha da hızlanır.

INSERT olunca işler değişir, sadece 1 field doldurup onu EXECSQL ettiğinde bile diğer 99 alan için partition işlemi yapılır. Bir de INDEX'ler varsa onların tipine göre de ek RAW data oluşturulur. Dolayısıyla SELECT ile INSERT satırlarının hızlarının farkı bununla basitçe özetlenebilir.

Şimdi alan sayısını azaltıp tablolara ayırdığınızda bu işlem INSERT aşamasında çok büyük kolaylık sağlar. Hem veri trafiği azalır çünkü tablolar arasında başvuru yapılan id kodlar konuşur hem de daha az karmaşık tablolara sahip olursunuz.
Saygılarımla
Muharrem ARMAN

guplouajuixjzfm15eqb.gif


Cevapla
#9
Merhaba,

Telefondan cevap yazayım dedim, ama bir süre sonra pes ettim Smile

Aslında kayıt sayısı ile INSERT hızı arasındaki ilişki çok dikkate değer değil, ama bu işin teorik kısmı (B-Tree'lerde tree'yi büyütmesi gerektiği zaman fark ortaya çıkıyor, ama bunun genel performansa eksi yönde etkisi çok değildir diye tahmin ediyorum). Pratikte 60 alanlık bir tabloda birden fazla index olacak ve bu da INSERT hızını düşürecek. Ben hızı düşürür diye yazarken bunun teknik açıklamasını değil, Mikro'nun veri tabanında gördüğüm günlük uygulamasını referans almıştım. Belki de Mikro'nun veri tabanında index fazladır diyeceğim, ama öyle de değil Smile Neyse, çok karıştırmayalım bu kısmı.

Tablo parçalamayı sadece normalizasyon olarak değil, optimizasyon olarak da düşünün. Vertical Partitioning diye bir yöntem var, tam da örnek verdiğim kimlik bilgilerini farklı bir tabloya almak anlamına geliyor. Bir tablonun, bir satırının byte miktarı ne kadar yüksekse IO operation'lar da o maliyetli olacak. SELECT cümlesinde az seçmeniz IO işlemlerinden tamamen kurtulmanız anlamına gelmiyor. Sonuçta seçmediğiniz alanlar da atlanacak (disk bazında düşünün). Yani sütun sayısının fazla olması her şartta tablo işlemlerini yavaşlatacak.

Sonuç olarak benim tavsiyem, kayıt sayısından bağımsız olarak, çok sütunlu tablolardan kaçınmanız ve veri tabanı tasarımı yaparken hem normalizasyon, hem de vertical partitioning konularını dikkate almanızdır. Buna göre 60 sütunluk bir tablo konusunda benim ikna olmam çok zor Smile

İyi çalışmalar
Cevapla
#10
Hızı belirleyen Kayıt Sayısı / INSERT bağlamı değil, Field sayısı / INSERT bağalmı. Yanlış anlaşılmışsa bunu kayıtlara geçsin diye yazma gereği duydum.

INSERT hızı konusunda hesap basit. Index'i silin bir INSERT yapın bir de silmeden INSERT yapın. Fark kabul edilebilir ise Index yapınız optimum verimde, değilse Primary - Secondary, Clustered tercihlerinizi yeniden değerlendirin.
Saygılarımla
Muharrem ARMAN

guplouajuixjzfm15eqb.gif


Cevapla

Konuyu Paylaş : facebook gplus twitter





Konuyu Okuyanlar: 1 Ziyaretçi