Birden fazla id tutulacak tabloyu parçalamak mı yoksa tek tabloda birleştirmek mi man

[onurakman]

Herkese merhaba,
Bir projem var projede; 
- Stok Tablosu; stok kartımdaki stokları MAMUL ve HAMMADDE olarak iki tipte tutucam.
- Stok Hareketleri Tablosu; Stok giriş-çıkış işlemlerinin tutulduğu tablo. 
- Sipariş Tablosu; Müşteriden alınan siparişlerin tutulduğu tablo,
- Üretim tablosu; Mamul üretiminin tutulduğu tablo,
- Sevkiyat Tablosu; Sipariş verilen mamullerin sevkiyat kayıtlarının tutulduğu tablo.

Kafama takılan soru ise şu;

Mamulleri barkod bazında takip etmek istiyorum, Yani stok hareketlerine stok girişi olduğunda 3 Adet mamul girişi olursa bu girişin detayında aslında 3 satır olarak tutmak istiyorum. Yani 3 farklı barkod oluşmuş olacak. 

Tabiki her barkod hangi üretim emri ile üretilmiş, hangi sevk numarası ile sevk edilmiş, hangi sipariş için istenmiş gibi detay bilgilerinide tutucam.
Bu bilgileri Stok hareket tablosuna bağlı farklı tablolar açıp orda mı tutmak mantikli yoksa her barkod için zaten bir satır açılacağından tüm id leri barkodun satırında mı tutmak mantıklı.

Farklı tablo olduğunda her sorgumda joinler oluşturmam gerekecek, tek tabloda sadece Where ile sonuca ulaşabilicem ama boş alanım çok fazla olacak.

Hangi yöntem daha hızlı ve sağlıklı olur?

[mustafaozpinar]

Selamlar, bu tür ikilem denilebilecek türden seçimlerle sık sık karşılaşıyoruz. Aslında bunlarla ilgili olarak karar vermek için anahtar noktalar belirleyip bunları puanlandırmak ve sonrasında bu puanları toplayarak sonuca varmak en doğrusu.
Anahtar noktalar,
1- Sorgulama hızı, ağırlığı %60
2- Karmaşıklık, ağırlığı %40
A durumu bir arada tuttuğunuz, B durumu ise ayrı ayrı tuttuğunuz durumlar olsun,
A-1 : %10 artar (çünkü diğer konularda sorgu çalıştırdığımızda bu alanlar onların da yavaş çalışmasına neden olabilir)
A-2 : %0 (join gerektirmeyen sorgu diğerinden daha kolay olacaktır)
B-1 : %5 (Çünkü join nedeniyle hız biraz düşecektir)
B-2 : %45 (ayrı bir kaydın bakımı zorlaşacak ve join nedeniyle sorgu biraz karmaşıklaşacaktır)
A : %6
B : %3 + %18=%21

Bu veriler kabul ediliyorsa A seçilmelidir.

Denilebilir ki, her seferinde böyle bir hesaplama mı yapacağız?
Bu size bağlı, ister yaparsınız, isterseniz de hislerinize güvenirsiniz. Ama şu kesin ki bir süre sonra bu hesaplamaları kafadan yapacak duruma gelirsiniz.

[m_ekici]

İlgili kayda ait Resim, uzun not/açıklamaları farklı bir tabloda tutuyorum.
Sürekli ihtiyaç duyulan alanları faklı tablolarda tutmak bence mantıklı değil.
Logo nun stok hareket tablosunda (STLINE) 300 adet alan var, bununla beraber 26 adet index kullanıyor.

[esistem]

(09-01-2020, Saat: 21:30)emre21 Adlı Kullanıcıdan Alıntı: bu sebeple datayı bir noktadan sonra
veritabanına işletmek yerine kendin bir bellekde array map ile işleme yoluna gitmen çok daha hızlı sonuç almanı sağlar,
ben sana 1milyon record içinde isteğin bir recordu 0.01 ms içinde kodla erişmenin yolunu tarif edebilir, ancak bunu veritabanı ile yapamazsın.

Şu olayı hep merak etmiştim, mümkünse ayrı bir başlıkta makale niyetine, yol gösterici birkaç bilgi paylaşabilirmisiniz ?

[serdar]

Merhaba 
Su an için indexlerini gerekli olanlarını iyi belirlemeni tavsiye ederim.
Birde bende benzer bir durumla karsı karsıya kaldım . 2010 yılından berı stoga gıren ve cıkan urunlerı kaydettım. 
su ankı stok durumunu ıse tum bu yıllar boyunca olusan giris hareketlerini toplayıp, sonra cıkıs hareketlerini toplayıp bırbırınden cıkrattım.
sonucta yuzbınlerce kayıt oldugundan sorgulamada yavaslama yasadım.
mesela su an x urunden ne kadar var sorusuna yukarıdakı ıslem yapıyordum.
Şoyle bır çözüm getirdim. Aylık ve Yıllık stok durumunu tutan ara tablolalar yaptım.
Bu tablolara, hareketler tablosunun trıggerları vasıtası toplamsal degerlerı atarak guncel kalmasını sagladım. 
Bir nevi her bir stok hareketınde  recalculate yapan bır yapı oldu.
Tabı trgıggarı ıyı kodlamalısınız kı verı butunlugu bozulmasın.
Sonucta 10 yıllık surecte toplamları gorme  ıhtıyacım var ıse her bir urun için su an yıllık tablomda 12 kayıt, aylık tablomda 120 kayıt var.

[adelphiforumz]

Yapmak istediğin işin sonuca giden birçok yolu mevcut.
Arkadaşların yazdıklarının dışında ben farklı bir konuya değinmek istiyorum.

Bu veritabanını çalıştıracağın bilgisayarın gücü ve kapasitesi nedir. ?

Bir örnek vermek gerekirse 
Sen öyle mükemmel bir database dizayn edersin ki müşterin kalkar nuh nebiden kalma bir makineye kurulum yapar sen ne yapsan boşadır.
Sen öyle bir berbat veri tasarımı yaparsın ki kurduğun makine yüksek hızlı diskler, sanallaştırma, Yüksem RAM, Yüksek CPU budurumda yaptığın tasarım hatası fark edilmez bile. 
(Genel de piyasada erişimler yavaşlayınca hemen ram, cpu arttırımına gidilir kimse nedenini araştırmaz malesef)

Bir veritabanı dizayn edilirken dikkat edilmesi gereken bir kaç konu vardır. Bunlar çok basitçe aklıma gelenler
1. Veri bütünlüğünü korumak.
2. Tablolar arasında bağlantılarını ve indexlerini minimum yapıda tutmak.
3. Insert ve Update yoğunluklarına göre verileri tutmak ve indexleri buna göre ayarlamak. (Düşünki saniyede 100 kayıt atacaksın sisteme bolca triger yazmışsın çık çıkabilrsen işin içinden)
4. Yüksek yoğunluklu veri erişimlerinde Memory Table kullanmak. (imkan dahilinde ise) (Web sayfalarına veri basmak ürün kataloglama gibi)
5. Analiz ve istatistik tablolarını belirli periyodlarda ayırmak. (Dönemi kapanmış verilerden genel bir istatistik oluşturmak ve istek durumunda arşiv gibi kullanmak)
6. Dönemsel oluşabilecek kayıtların tablolarını ayırmak. (@serdar ın bahsettiği konu)
7.... Bu liste böyle uzayıp gider

---

(10-01-2020, Saat: 09:24)esistem Adlı Kullanıcıdan Alıntı:

(09-01-2020, Saat: 21:30)emre21 Adlı Kullanıcıdan Alıntı: bu sebeple datayı bir noktadan sonra
veritabanına işletmek yerine kendin bir bellekde array map ile işleme yoluna gitmen çok daha hızlı sonuç almanı sağlar,
ben sana 1milyon record içinde isteğin bir recordu 0.01 ms içinde kodla erişmenin yolunu tarif edebilir, ancak bunu veritabanı ile yapamazsın.

Şu olayı hep merak etmiştim, mümkünse ayrı bir başlıkta makale niyetine, yol gösterici birkaç bilgi paylaşabilirmisiniz ?

Açıkçası bende bu konuyu şimdi merak etmeye başladım bu güne kadar her şeyi veritabanı üzerinde çözmek için uğraşıyordum. Böyle bir yol varsa neden kullanılmasın. Bu konuda @esistemin dediği gibi ayrı bir başlıkta öğrenmeyi isterim.

[esistem]

Verdiğiniz bilgiler için teşekkürler @emre21 , PHP de anlattığınız olayı zaten mecburen kullanıyorum, milyona ulaşan-geçen kayıtlarda sql ile işlem yaptığınızda zaten sunucu sizi şutluyor Delphi ile nasıl yapılır olayını merak etmiştim. Bazı durumlarda PHP (veya benzer diller) gibi esnek olmaması handikap olabiliyor tabi.

[adelphiforumz]

@emre21 bilgilendirme için teşekkürler