Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 5/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Tablodaki field sayısı ne kadar önemli
#31
(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

Yazdıklarınıza ilave olarak şunları da belirteyim: Null olarak oluşturulup, sonradan değeri girilen bir alan, index kütüğüne null olmayan bir veri girildiğinde yazılır; 0 yazıp sonradan update ederseniz index kütüğüne yazılır ve sonradan kütükten silinip tekrar yazılır yani maliyetler ciddi anlamda artar. Initial değere sahip kayıtlar filtrelenip, bulunması gereken kayıtlar değilse, bu maliyete değmeyecekse çoğu zaman initial değerin boş olması en doğru ve ucuz (uygun) yöntemdir.
Cevapla
#32
(30-03-2018, Saat: 09:35)masteryoda Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(30-03-2018, Saat: 09:09)esistem Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlBence işin o kadar derin detayına girmeyin, ben yıllardır kendi yazdığım programı kullanıyorum çalıştığım yerlerde, ayrıca sattığım da onlarca firma var, bunlar arasında yılda 50k fatura kesende var 1k kesende var, tek kullanıcıdan 10-12 kullanıcıya kadar kullananda var. Hiçbir zaman herkesin aynı kişiye fatura kesmeye çalıştığını veya sipariş girmeye çalışırken programın çaktığını görmedim duymadım. Cari hesapları tanıtan 1-2 kişi oluyor, stokları tanıtan 1-2 kişi oluyor ve bunlar şimdiye dek hiç aynı stoğu güncellemek yada biri silerken diğeri kaydetmek istemedi. Genelde işleyiş, kayıt ekleme (fatura-irsaliye-sipariş-ödeme-tahsilat vs.) üzerine olduğu için böyle bir çakışma yaşamanız çok çok düşük bir ihtimal. Cari hesap açılır, sürekli onun üzerine alt kayıtlar (işlem kayıtları) girilir, stok kartı açılır aynı şekilde hareketleri girilir. Hareketi olan bir cari yada stok kartı da silinemeyeceğine göre böyle bir ihtimali düşünmek bence mantıksız oluyor.

Hocam yanyana oturan iki kişinin aynı siparişte değişikliğe gitiğini çok gördüm henüz yapmadım ama benim önerim şu şekilde olurdu daha kolay daha etkin bir yöntem olabilir tabiki

örnek acik_islemler isimli bir tabloda kullanıcının değişiklik yapmak istediği anda o  tablo adı, record_id ve kullanıcı_id sini tutmak örnek
başka biri değişiklik yapmak istediğinde önce o tabloda sorgulatıp bu kaydı x kişisi şuanda düzenliyor şeklinde bilgi vermek daha mantıklı geliyor bana düzenleyen kişi işini bitirdiğinde o kayıt silinebilir.

Öneriniz için teşekkürler. Yöntem genel olarak sorunsuz çalışabilir. 
Fakat bazı istisnalar hariç. A kişisi kaydı seçti. acik_islemler tablosuna atti. Sonra bir sebeple bu kisinin programı hata verip kapandı veya elektrik kesildi vs.. Bu durumda bu kayıt açık kalacaktır.
A kişisi tekrardan bu kaydi açıp işini bitirip kapatıncaya kadar baska hic kimse bu kayda dokunamayacaktir.
(Benzeri bir yapıyı programımın birisinde uygulamıştım. Yukarıdaki bahsettiğim sorunlarla karşılaştım)
Cevapla
#33
Çok güzel bir başlık oldu, ilgiyle izledim. 

Son sorunsala ilişkin uyguladığım bir yöntemi paylaşayım; 

projelerimde sürekli açık tablo veya dbgrid için dahi sql dataset vb.  bulundurmuyorum. Bu benim kişisel bir tercihim. (listview ile görseli kontrol edebiliyor olmayı seviyorum) 

state (edit veya insert öncesi veri girişi) durumunda ben token tablosuna tarih saat bilgisi ve veri giriş veya değişikliği yapılacak proje modülü (tablo demiyorum çünkü bir sürü tablo veri girişinden etkilenebilir) kaydını düşüyorum. 

Karşılaşılması muhtemel gördüğünüz kilitli kalma ihtimaline zaman aşımı şartı koyunca alabiliriz. 

Ben de 60 sn süre içinde veri girişi için bekleyen kullanıcıdan süre uzatım (ping de diyebilirsiniz) 60 sn daha ekleniyor. Taa ki post (execsql) işlemine kadar. zaman aşımında başka kullanıcı token alıyor. 

Eski kullanıcı token sahibi değilse kayıttan önce ilgili tabloya ilişkin yeni değişiklik ekrana raporlanıyor ve kendi kaydı bekleyen işlemlere alınıyor. 

İnceleme sonucu kayıt etmek isterse yeni giriş gibi değerlendirip giriş yapıyor. Güncelleme ise diğer kullanıcının yaptığı kaydın son hali karşısına geliyor bunun üzerinden işlem yapmak zorunda kalıyor.
Saygılarımla
Muharrem ARMAN

WE75nm.gif


Cevapla
#34
(30-03-2018, Saat: 09:35)masteryoda Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(30-03-2018, Saat: 09:09)esistem Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlBence işin o kadar derin detayına girmeyin, ben yıllardır kendi yazdığım programı kullanıyorum çalıştığım yerlerde, ayrıca sattığım da onlarca firma var, bunlar arasında yılda 50k fatura kesende var 1k kesende var, tek kullanıcıdan 10-12 kullanıcıya kadar kullananda var. Hiçbir zaman herkesin aynı kişiye fatura kesmeye çalıştığını veya sipariş girmeye çalışırken programın çaktığını görmedim duymadım. Cari hesapları tanıtan 1-2 kişi oluyor, stokları tanıtan 1-2 kişi oluyor ve bunlar şimdiye dek hiç aynı stoğu güncellemek yada biri silerken diğeri kaydetmek istemedi. Genelde işleyiş, kayıt ekleme (fatura-irsaliye-sipariş-ödeme-tahsilat vs.) üzerine olduğu için böyle bir çakışma yaşamanız çok çok düşük bir ihtimal. Cari hesap açılır, sürekli onun üzerine alt kayıtlar (işlem kayıtları) girilir, stok kartı açılır aynı şekilde hareketleri girilir. Hareketi olan bir cari yada stok kartı da silinemeyeceğine göre böyle bir ihtimali düşünmek bence mantıksız oluyor.

Hocam yanyana oturan iki kişinin aynı siparişte değişikliğe gitiğini çok gördüm henüz yapmadım ama benim önerim şu şekilde olurdu daha kolay daha etkin bir yöntem olabilir tabiki

örnek acik_islemler isimli bir tabloda kullanıcının değişiklik yapmak istediği anda o  tablo adı, record_id ve kullanıcı_id sini tutmak örnek
başka biri değişiklik yapmak istediğinde önce o tabloda sorgulatıp bu kaydı x kişisi şuanda düzenliyor şeklinde bilgi vermek daha mantıklı geliyor bana düzenleyen kişi işini bitirdiğinde o kayıt silinebilir.

Dediğiniz şekilde bir uygulama yapılabilir, fakat ben daha ihtiyaç duymadım zira problem çıkacağını düşünmüyorum. Neden böyle derseniz, kayıt ve değişiklik işlemlerinde memory table kullandığım için derim bende. Anlattığınız durumda olabilecek en büyük sorun şunlar olabilir. Birisi siparişi girdi kaydetti, aynı anda 2 kişi açtı değişiklik yapmak istiyor. Açık query olmadığı için lock hatası vermez, server işlemleri sırayla uyguladığı için kayıt esnasında hata vermez (SP ile yapılıyor hepsi). Bekleyen (açık) transaction olmadığı için limbo trans. oluşmaz dolayısı ile kayıt esnasında hata vermez. Biri kaydı silsede diğerinin değişklik yap kaydet dediği sp ilgili kodları bulamayacağı için boş geçer hata vermez, vs.vs. gibi. En çok "aaa aynı anda düzenlemişiz , gel düzeltelim tekrar" denir diye düşünüyorum Smile
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#35
(30-03-2018, Saat: 12:07)esistem Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(30-03-2018, Saat: 09:35)masteryoda Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlHocam yanyana oturan iki kişinin aynı siparişte değişikliğe gitiğini çok gördüm henüz yapmadım ama benim önerim şu şekilde olurdu daha kolay daha etkin bir yöntem olabilir tabiki

örnek acik_islemler isimli bir tabloda kullanıcının değişiklik yapmak istediği anda o  tablo adı, record_id ve kullanıcı_id sini tutmak örnek
başka biri değişiklik yapmak istediğinde önce o tabloda sorgulatıp bu kaydı x kişisi şuanda düzenliyor şeklinde bilgi vermek daha mantıklı geliyor bana düzenleyen kişi işini bitirdiğinde o kayıt silinebilir.

Dediğiniz şekilde bir uygulama yapılabilir, fakat ben daha ihtiyaç duymadım zira problem çıkacağını düşünmüyorum. Neden böyle derseniz, kayıt ve değişiklik işlemlerinde memory table kullandığım için derim bende. Anlattığınız durumda olabilecek en büyük sorun şunlar olabilir. Birisi siparişi girdi kaydetti, aynı anda 2 kişi açtı değişiklik yapmak istiyor. Açık query olmadığı için lock hatası vermez, server işlemleri sırayla uyguladığı için kayıt esnasında hata vermez (SP ile yapılıyor hepsi). Bekleyen (açık) transaction olmadığı için limbo trans. oluşmaz dolayısı ile kayıt esnasında hata vermez. Biri kaydı silsede diğerinin değişklik yap kaydet dediği sp ilgili kodları bulamayacağı için boş geçer hata vermez, vs.vs. gibi. En çok "aaa aynı anda düzenlemişiz , gel düzeltelim tekrar" denir diye düşünüyorum Smile

Gorev atamali bir sistem dusunun  atama yapmaya 2 kisi yetkili A kisisi X kaydını B kisine atadı  C kiside X kaydını D kisine atadı.  ve bu Farkedilmedi ve gorev kagitlarini alıp yola ciktilar.
Bir anda aklima gelen bir senaryo mesala. Ayrıca bir çok defa çeşitli projelerimde karşılaştım. Bir birinden farkli şehirlerde 100 lerce kullanıcı düşünün.
Bence herşey sorunsuz olsa bile  "aaa aynı anda düzenlemişiz , gel düzeltelim tekrar" demek bile aslında başlı başına bir sorun Smile
Cevapla
#36
Bahsettiğiniz senaryoda dediğiniz gibi problemler ortaya çıkabilir, fakat bu, programcının hatası olacaktır. 2 kişi yetkili, ortada 2 görev 2 veya daha fazla da görevli var, a görevine bir kişi b görevine bir kişi lazım, sistem RDBMS çalıştığı için işlemler mecburen sırayla yapılacaktır (SP ler ile). Atanan kişiye ve boştaki göreve birer alan konulup (byte tipinde 0-1 şeklinde) atama yapıldığında da bu alan 1 yapılırsa 2. görevi veren kişiye bir uyarı gidebilir ve kaydı geri alınır, oda "bu göreve biri atanmış" veya "bu kişi zaten görevlendirilmiş" diyebilir. Aynı Cari ve Stok işlemlerindeki mantık gibi, eğer hareket varsa başıboş kayıt kalmasın diye bunu silemezsiniz diyorsanız, bu işlem zaten yapılmış senin ne işin var bununla diyebilirsiniz.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter





Konuyu Okuyanlar: 1 Ziyaretçi