silinen id gösteren sql

[droxee]

s.a.
hayırlı cumalar..
benim sorum : select id,ad,soyad from tbl_bilgi tablosunda id ler 1,2,3,... şeklinde listelediğim tabloda sildiğim id leri nasıl listelerim? örneğin 2 nolu kaydı sildiğimde 1,3,4... şeklinde değilde sadece silinen 2 nolu id yi gösterecek..

[true_false]

Veritabanından hard(DELETE) olarakmı siliyorsun. eğer siliyorsan yapma. her tablona [silindi] int[1] bir field ekle ve default olarak "0" ver ve her sorgunun where koşuluna ".... where silindi=0" olarak sorgu çek.
silme yaptığın zamansa [silindi] değerine 1 olarak update geç.
bu tarz kullanım veri kaybının önüne geçecektir.
veri tabanından delete komutuyla silinen bir veriyi geri alman çok zor. Oracle'da flashback query var ama oda db adminin verdiği imkanlar doğrultusunda. Geriye dönük 1 haftalık flashback query çekmen çok zor hatta imkansız olabilir.

[mrmarman]

Merhaba.

Arada ardışık olarak iki kayıt silinmemiş olsa, bir üç kağıt ile çözülebilecek bir şey ancak handikaplı. Şöyle ki...

Olur mu olmaz mı sorusunu kendi projemde denedim. Ne yaptım ? YHI_KaySiraNo benim autoinc alanım... Tablom da anlaşılacağı üzere YAPIMHAREKETILGI

Şöyle bir çıkarımda bulundum, her kayıt için bir sonraki kayıt numarası yoksa bunu göster şeklinde bir metod. Şartlı olarak işe yarıyor ancak art arda iki tane kayıt silinmişse, bir sonraki kayıt nosunu bulabileceğim aradaki kayıt da olamayınca ne yapsın SQL.

Kod: Tümünü seç

Select Top 100 YHI_KaySiraNo + 1 from ProduksiyonDB.dbo.YAPIMHAREKETILGI T1
where not exists 
   (select * from ProduksiyonDB.dbo.YAPIMHAREKETILGI T2 where T2.YHI_KaySiraNo = T1.YHI_KaySiraNo + 1)
order by YHI_KaySiraNo asc

Şimdi bir tablo create edip, eksik kayıt ID'lerini kontrol edeceğin Tablonun MAX( autoinc alanı ) kadar bir rakam girişi yaparsan, bir JOIN ile şak diye bulursun. Sonra da bu tabloyu DELETE edersin.

Bunu yapacağına da daha basiti, bir TStringList'e 1'den başlayıp eksik kayıt ID'lerini kontrol edeceğin Tablonun MAX( autoinc alanı ) kadar sıralı numara koyup, aynı tablonun başından sonuna kadar sıralı dolaşarak, TStringList'de IndexOf ile bu numara oluşturulan listeden düşülerek, geriye kalan rakamlar olmayan kayıtlardır sonucuna varabilirsiniz.

Ama güzel soru, cevabı varsa ben de öğrenmek isterim.

Bu arada @true_false'a katılıyorum, kendi tablolarımda da hep bir silindi alanı bulunduruyorum. Ayrıca kimin sildiğini de loglamak için Guncelleyen ve GuncellemeTarihi de yer alıyor. Tavsiye ederim.

[freeman35]

Kuyum programında adamlar ultra paranoyak olduklarından, hiç bir kayıt silinmiyor, bu true_false ın dediği yöntemle yapılıyor, diğer tüm işlemler log lanıyor, ben Firebird kullanıyorum, after delete, insert, update triger larını ile tüm yapılan işlemleri ki bunun içinde hangi field, hangi değerin hangi değerle değiştiği, kiminyaptığı vs her şey kaydediliyor

[droxee]

cevap yazan herkese cok tesekkur ederim ozellikle de muharrem hocam cok sagolun sizin metodu kullanacam..

[mrmarman]

Hocam benim gösterdiğim sana tüm eksikleri göstermez. Bunu bilerek kullan. Sadece hangi aralıklarda eksik varsa onun ilkini bulur. Takip eden ikinci üçüncü vs. kayıt noları çıkmayacaktır.

Örneğin
1,2,4,5,7,8
iken ve
1,2,5,7,8
iken de aynı 3,6 sonucunu verir.

[thelvaci]

Kayıt silinmesi yerine, ilgili kaydın bir değer vasıtası ile işaretlenmesi ve güncellenmesi hususundaki genel görüşünüze maalesef iştirak edemeyeceğim. Bazı durumlarda, belki bu bir ihtiyaç olabilir; bu yönde istekler de olabilir; ancak sürekli bu şekilde kullanmak ilerleyen zamanlarda performansa ciddi anlamda olumsuz etkide bulunacaktır. Çok özel durumlar haricinde, siz siz olun tablonuzdaki kayıtları kullanıcı siliyor ise; siz de silinmesine müsaade edin, silmek yerine güncellemeyin.

[mrmarman]

Tuğrul bey, dönemlik bakım yapılabilir. Dolayısıyla dilenen kayıtlar -performans düşüş kaygısı da haklı bşr gerekçe çünkü- sonradan yedeklenip silinir. Ancak silinmiş kayıtlar geri gelmez. Kullanıcıların yaptıkları proje sahiplerine mal olur. Eşeği sağlam kazığa bağlamak yeridir. Özellikle künye kayıtların silinmesi bile tüm detay kayıtlarının silinmesini gerektirir. Neyin ne zaman lazım olacağı ilk anda genellikle akla gelmez. Sonra ayrıca kahraman olursunuz servis ücretiniz de artar. Bunlar ucuz kahramanlık da değil bilirsiniz.

[thelvaci]

Peki o zaman ufak efek sıkıntıları biraz daha açayım madem:

Birinci sıkıntı herkesin tahmin edebileceği gibi, ilgili tablolarda çok fazla kayıt olmasından mütevellit sorguların dramatik seviyelerde yavaşlayabilmesi ihtimalidir.

İkinci sıkıntı ve belki de en risklisi; programcının yaptığı sorgularda tüm tablolar için IsDeleted = 0 gibi kısıtlar kullanması zorunluluğu ve bunu yazmayı kolaylıkla unutabileceği gerçeğidir.

Üçüncü sıkıntı, birden fazla tablonun birbirine join ile bağlandığı noktalarda ortaya çıkar.

Örneğin:

Kod: Tümünü seç

  SELECT A.Field1, B.Field2
  FROM TableA AS A
    INNER JOIN TableB AS B ON A.ID = B.TableA_ID
  WHERE
    A.IsDeleted = 0 AND
    B.IsDeleted = 0

gibi bir sorguda görüldüğü üzere tablolar birbirleri ile silinmiş kayıtlarda dahil olarak joinleniyorlar, hemen ardından programcı unutmaz ise doğru sonuçları elde edbilmesi için IsDeleted alanları üzerinden filtreleniyorlar. Silinmiş kayıtlarda dahil olarak joinlenen tablolar performansa olumsuz etki edecektir. Bunun önüne geçmek için yukarıdaki sorguyu aşağıdaki hale dönüştürmeniz icap eder:

Kod: Tümünü seç

  SELECT A.Field1, B.Field2
  FROM
  (
  	SELECT ID, Field1
  	FROM TableA
  	WHERE
  		IsDeleted = 0
  ) AS A 
  INNER JOIN 
  (
  	SELECT ID, Field2, TableA_ID
  	FROM TableB
  	WHERE
  		IsDeleted = 0
  ) AS B ON A.ID = B.TableA_ID

Görüldüğü üzere bu da pek şık bir çözüm değil.

Bir başka sıkıntı ise; çok fazla kayıt içeren tablolarda bulunan index'lerin de bir kaç tane olması durumunda, kayıt eklemenin ve güncellemenin de ciddi anlamda yavaşayacağıdır.

Aklıma gelen, yazdığım ve aklıma gelmeyen tüm bu olumsuzluklara rağmen yine de tercih sizlerin elbette.

Demeye çalıştığım şey; bu düşüncenin genel anlamda sıkıntılı ve hatalı bir düşünce olduğudur; ancak bu tarz bir yapıya ihtiyaç olmaz mı elbette olur. Bu çözüm ancak o zaman değerendirilmelidir. Yani varsayılan davranış olarak kabul edilmemelidir.

[mrmarman]

Demeye çalıştığım şey; bu düşüncenin genel anlamda sıkıntılı ve hatalı bir düşünce olduğudur;
... Yani varsayılan davranış olarak kabul edilmemelidir.

Yabancıların sıkça kullandığı bir lafı vardır, "Agree to disagree" ( anlaşamadığımız konusunda anlaşalım )

[thelvaci]

Demeye çalıştığım şey; bu düşüncenin genel anlamda sıkıntılı ve hatalı bir düşünce olduğudur;
... Yani varsayılan davranış olarak kabul edilmemelidir.

Yabancıların sıkça kullandığı bir lafı vardır, "Agree to disagree" ( anlaşamadığımız konusunda anlaşalım )

Ben sadece durum tespiti yapıp; bizzat tecrübelerime istinaden konuştum. Sizinle ortak bir paydada buluşmamız ne size ne de bana bir şey kazandırmaz da kaybettirmez de; lâkin yazılan yorumlara istinaden programlamaya yeni başlayacak yada yolun başında olan arkadaşlar; bahse konu silme işlemi yerine güncelleme yolunu tercih ederler ise; ileride başları epey bir ağrıyacaktır.

Tercih meselesi elbette, maksadımız eleştirmek değil; dediğim gibi tecrübelerin aktarılmasıydı.

[aLonE CoDeR]

Tuğrul maalesef ben de silinen kayıtların ciddi bir performans sorununa sebebiyet vereceği konusuna iştirak edemeyeceğim, kayıt silme işlemi sürekli ihtiyaç duyulan ve uygulanan bir işlem değil ki böyle bir duruma sebebiyet versin. Her üç kayıttan birini yanlış girip siliyorsa kullanıcı evet bu olabilir, ama silinen kayıtlar tüm kayıtların yüzde kaçına tekabül eder ki? Ve zaten böyle bir sorun olsa veritabanları benzer bir yöntemi neden kullanır ki?

[vkamadan]

MErhabalar ,
Benzer durumları MySQL üzerinde çalışan bazı projelerimde kullanıyorum tüm tabloların "vw" ön ekiyle birde viewleri var sorgularda view versiyonlarını kullanıyorum bu sayede statik "WHERE" leri hazır şekilde gelmiş oluyor değişikliği VIEW de yapıyorum projenin tamamında etkili olmuş oluyor, bu şekilde Tuğrul beyin belirttiği sorgularda unutma ve sorgunun karmaşıklaşması sorununu daha kabul görür hale getirebilirsiniz.

[veliadiguzel]

Dlete trgigeri ile silinen id leri bir table da toplaya bilrisin. bir nevi loglama gibi bir ara uygulamıstım silinen kayıtları temp_ table da saklıyordum.

[thelvaci]

Tuğrul maalesef ben de silinen kayıtların ciddi bir performans sorununa sebebiyet vereceği konusuna iştirak edemeyeceğim, kayıt silme işlemi sürekli ihtiyaç duyulan ve uygulanan bir işlem değil ki böyle bir duruma sebebiyet versin. Her üç kayıttan birini yanlış girip siliyorsa kullanıcı evet bu olabilir, ama silinen kayıtlar tüm kayıtların yüzde kaçına tekabül eder ki? Ve zaten böyle bir sorun olsa veritabanları benzer bir yöntemi neden kullanır ki?

Ben; "kayıt silme işlemi" performans problemi yaratır demiyorum ki! Tam aksini söylüyorum. Silinmesi gereken kayıtların, silinmesine engel olunup, silindi olarak işaretlenmesinden bahsediyorum. Ayrıca; "tecrübelere binaen" diyorum; hâla inandırıcı olamıyor isem sorun değil, buyursun denesin arkadaşlar. 2-3 kişinin kullandığı programlarda belki bu söylenenlerin ispatını gözlemleyemezsiniz ama şöyle 100+ kulanıcının bağlandığı yoğun transaction alan sistemlerde ne demek istediğimi çok daha iyi anlayacak arkadaşlar.

Ayrıca; veritabanları hangi benzer yöntemi kullanıyor acaba ? Ben SQL Server'da bahse konu bir yöntem görmedim. Aksine silinen kayıtların başka bir şekilde log'landığı CDC yapısını kulanıyor SQL Server. Yani kullanıcının silme isteğinin önüne engel koymuyor, eğer kullanıcı ister ise ilgili kaydın log'unu bir başka tablo üzerinde tutuyor.