Hocam sorgularını optimize etmeyi denedin mi? herkes programcı olmak zorunda değildir, lütfen bir zorunluluk gibi programlama dilleri ğrenmeye çalışmayın. yabancı dil filan ğrenin amq.// s. kimin etini yerim, kasaba minnet etmem.// ince düşünene kalın girer.//

İlerde bi işine yaramayacak datayı veritabanında tutmanın mantığı yoktur. Yanlışlıkla silinmenin nüne geçmek istiyorum diyorsan da ay başında çift ynlü backup alıp komple kaldırabilirsin. Adam facebook da "Bugün kebap yapıyorussss" diye paylaşıp sonra bunu silmiş. Bunu db de tutsan ne tutmasan ne? Ekstra maliyetten başka birşey getirmez, nemli olan senaryo. Herşey şyledir herşey byledir denemez. Hello, i am nothing. I come from Neverland.

Database'in tasarım esnasında zaten dikkat edilen unsurlardan bir tanesi gereksiz veri tekrarının nüne geçmektir. Buradan anlayacağımız üzere database içerisini nekadar temiz tutarsak okadar iyi. Bahsettiğin şey senaryoya gre değişebilen bir şey. x firmasının bir otomasyonunda her kullanıcının giriş ve işlem yetkisi olsun. Ali 1 senelik x firmasının çalışanı ve toplamda 5000 tane iş yürütmüş otomasyon üzerinde. Ali işten çıktığında otomasyon üzerinden kullanıcı silmek doğru bir seçenek olmaz. Çünkü yetkili abiler o 5000 tane işten rapor almak istediğinde o işi kim yapmış, nekadar zaman harcamış, neler yapılmış grmek ister. Bu durumda ali'yi pasif konuma çeker raporlarına doğru bir şekilde devam edersin. Ama aynı rnek üzerinden gidelim mehmet isimli çalışan işe giriyor sen bu adamın kaydını yaparken sisteme mehmet değilde memet yazmışsın. Bu kaydı sistemden komple silmen gerekiyor. Hiç kullanmayacağın bir datanın database içerisinde durmasının hiç bir gereği yok. Data sayın az iken farketmeyebilirsin fakat data sayısı arttıkça o fazlalıklar kendini hissettirecektir. Trigger olayına gelirsek tam ne için kullanıcağını anlamadım. Bir çok amaçla kullanılan bir yapıdır. Log tablosunun şişmesinde bir sakınca yok zaten database'in amaçı data tutmak. Sen log tablosu üzerinde sorgulamalarını yaparken tüm tabloyu çekmektense belirli tarih aralıklarını filtereyerek veya pagination yaparak sorgularını hafifletebilirsin.

Hocalarım şimdi bir soru soracağım. Bu zamana kadar hiç VT den veri silmedim en gereksiz tabloda bile. Genelde hep en sona isDeleted diye bir alan ekleyip boolean atıyorum. Sorgularımda da hep isDeleted=0 ekliyorum şart olarak. Bana Eksi olarak Sorgu süresi katıyor. Şimdi aklımda bir kaç saçma düşünce var isDeleted koyduğumda zaten hiçbir veriyi silmiyorum Veritabanında hiçbir veri silinmiyor ise Trigger mantığına gerek var mı? Trigger da çünkü Delete Select Insert işlemlerini Log altında tutmaya yarıyor . Zaten Delete işlemi olmuyor. VT den giden herhangi bir veri olmadığı için neden Trigger yapayım? Sorgu süresini Trigger mi daha cok etki eder yoksa isDeleted olarak koyduğum alan mı? Yaptığım iş saçma mıdır? isDeleted koymak yani. Siz neler yapıyorsunuz? Trigger ile Tablodan Işlem Tipi , Açıklama , Tarih ekledik diyelim burda silinen tüm satırı tutamıyoruz yani isDeleted muhabbeti daha iyi değil midir? Trigger koyarsam Log tablosu şişecek isDeleted koyarsam Çeşiktli tablolar şişecek. Buda bir etken Ne yapmam gerekiyor Yardımcı olabilecek biri? MhmdAlmz tarafından 26/Ağu/16 17:46 tarihinde düzenlenmiştir Andolsun kuşluk vaktine ve dindiği zaman o geceye ki, Rabbin sana veda etmedi ve darılmadı! Ve kesinlikle senin için sonu nünden daha hayırlıdır. ileride Rabbin sana verecek de hoşnut olacaksın! O, seni bir yetim iken barındırmadı mı? Seni, yol bilmez iken yola koymadı mı? Seni bir yoksul iken zengin etmedi mi? yle ise, sakın yetime kahretme ! El açıp isteyeni de azarlama! Fakat Rabbinin nimetini anlat da anlat!

@TeRRoR Hocam Sorguları optimize ediyorum her seferinde sıkıntı yok onda Tüm kriterleri ekleyerek sorgu yapıyorum hocam zaten @FCN Amaç şu hocam Piyasada yıllarını veren çok kişi var. Anlamak istediğim şu Neye gre Log tablosuna veri ekleriz neye gre tabloda aktiflik durumunu değiştirmemiz idi. Şu işten çıkma olayı vs. Anlattığında anladığım kadarıyla Birbirleri ile entegreli şekilde çalışan yapıları silmek yerine pasif etmek daha mantıklı rneğin ; Büyük bir firmanın 20 ye yakın bayii olsun. Herhangi biri kapandığında Onu silmek yerine Aktiflik durumunu değiştirmek Sorgulardaki hem hataları nleyecek hemde veritabanındaki ilişkili veriler yok olmayacak. Ama ufak tefek çerez sayılacak verileri yani ilişkileri olmayan en ufak dalları sildikten sonra Log tablosunda tutabiliriz. Güzel bi düşünce teşekkürler @KrypT, ğrenciysek olmuyor mu? :/ Andolsun kuşluk vaktine ve dindiği zaman o geceye ki, Rabbin sana veda etmedi ve darılmadı! Ve kesinlikle senin için sonu nünden daha hayırlıdır. ileride Rabbin sana verecek de hoşnut olacaksın! O, seni bir yetim iken barındırmadı mı? Seni, yol bilmez iken yola koymadı mı? Seni bir yoksul iken zengin etmedi mi? yle ise, sakın yetime kahretme ! El açıp isteyeni de azarlama! Fakat Rabbinin nimetini anlat da anlat!

Hocam eğer çok büyük bir database değilse, sorgu süresinin uzaması trafik olarak servera binen yükü arttırmıyorsa yaptığın işlem doğrudur. Tembel silme işlemi denir ona. Ama eğer, tasarım düzgün yapıldıysa, bir row silindiği zaman nemli veri kaybetmiyorsan, yani tabloları düzgün şekilde ayırdıysan silmek sorun yaratmaz.

Paran yoksa mantıklıdır. while (1<2)

Anladım zaten herkes aynı şeyi sylüyor. Mantığı az çok kavradım gibi veri büyük değilse sil gitsin . Andolsun kuşluk vaktine ve dindiği zaman o geceye ki, Rabbin sana veda etmedi ve darılmadı! Ve kesinlikle senin için sonu nünden daha hayırlıdır. ileride Rabbin sana verecek de hoşnut olacaksın! O, seni bir yetim iken barındırmadı mı? Seni, yol bilmez iken yola koymadı mı? Seni bir yoksul iken zengin etmedi mi? yle ise, sakın yetime kahretme ! El açıp isteyeni de azarlama! Fakat Rabbinin nimetini anlat da anlat!