silinen id gösteren sql

[aLonE CoDeR]

Doğru anladım da doğru ifade edemedim, yani silinmesi gerektiği halde silinmeyen ve silindi olarak işaretlenip gösterilmeyen kayıtlar performansa ne ölçüde ve hangi işlemlerde etki eder bunu irdeliyoruz ve benim şahsi kanaatim ve kısmi tecrübelerime dayanarak performansa etkisi kabul edilebilir düzeyde olacağı yönünde.

[esistem]

Selam,
İlgimi çekti konu. Şahsen bende kullanıcının sildiği kayıtları işaretlemek yerine direk sildiriyorum, aksi halde bütün sorgularınızı yeniden düzenleyip yazmanız icap ediyor, birde performans kaybı için tuğrul beyin dediği gibi çok fazla kullanıcı olmasına gerek yok. Mesela bir müşterim var hemen her gün 2-3 cilt fatura kesiyor ve tek kullanıcı. Fakat yıl sonuna gelindiğinde 50.000 civarı fatura kesmiş oluyor ve her faturada zaten 8-10 ürün olsa en az 400.000 fatura alt datası kaydı, kesilen fatura adedinin en az 2 katı kadar cari hesap hareket tablosu kaydı, 400.000 den fazla stok hareket tablosu kaydı vs.vs. oluşuyor. Fakat @aLonE CoDeR in dediği gibi silme işlemi sürekli yapılan bir işlemde değil. Ama şunuda düşünmek gerek, bir tek kayıt silinse de binlerce kayıt silinse de tablolarınız da sorgularınızı JOIN ile yapmak zorundasınız ve buda mutlaka performansı ters yönde etkileyecektir. O yüzden bencede kullanıcı silmek istiyorsa kaydı tablodan silin gitsin, fakat @mrmarman hocamızın dediği gibi kahramanlık göstermek isterseniz LOG tutun. Hangi kullanıcı hangi tablodaki hangi kaydı hangi IP den hangi saatte silmiş yada değiştirmiş atın bir LOG dosyasına gitsin. Yöneticide bunları günlük kontrol etsin olsun bitsin.

[freeman35]

Aman Tuğrul bey, "hâla inandırıcı olamıyor isem" bende şahsi tecrübemi paylaşayım, ben insanlara inandırmaya çalıştırmaktan uzun yıllar önce vazgeçtim. İhale hep bende kaldı çünkü Siz bildiğinizi, bilginizi, tecrübenizi paylaşın kim isterse uygular yada uygulamaz.
Dediğiniz son derece doğru, kaydı silmemek kayıt sayısını çoğaltmaktır, ve her select te where clause olmak zorunda yani kayıt ayıklanacak demektir, ayrıca yapılan her yeni kayıt, bu kullanıcı için anlamı olmayan "silindi" denilen kayıtlar, index yapılandırmalarında değerlendirilecekler.
Ben yukarıda yazdım, kuyum programımda silmemek zorundayım, müşteri böyle istiyor. Bende silme işini kullanıcı için en zor hale getirttim, hatta hiç bir query de delete sql yoktur. ancak ben db ye program haricinde müdahale edersem silebilirim onda dahi log var
Yani bu işlem doğrudur yanlış demek, bence yanlış, şartlar neyi gerektiriyorsa en uygun çözüm bulunmalı. Burada biz fikirlerimizi paylaşıyoruz, kim neyi kullanır kullanmaz kendi bilecekleri ve özellikle sorumluluklarındadır.
Herkese, aman diyeyim, zaten sayımız az, hepten seyrelmiyelim.Aksine çoğalalım.
Kolay gele

[veliadiguzel]

Arkadaşlar her ne kadar sizin kadar profesyonel olmasam da naçizane tecrübelerimi paylaşayım. Bence silinmesi gereken kayıt silinmeli !!! he kullanıcı bunu görmek isteyebilir. burda dediğiniz yöntemler devreye girer her nekadar where tümceciği olsada arka alanda uğraşacağı kayıt fazla laşacaktır. En optimum çözüm dediğiniz gibi logları tutmak olacaktır. çalıştığım firmada oracle +delphi uygulaması yazan rus (yanlış anlaşılmasın süper bir prıgramcı ruslar felan gibisinden demedim adam rus işte ) bir programcı ile beraber (1-2 kere ) çalışma fırsatım oldu adamlarda mantık normal çalışan db birde historical dediği artık işi bitmiş yada kullanılmayan kayıtların bilgilerin tutulduğu database olarak tasarlamışlar bana mantıklı geldi sürekli çalışılan database i mümkün oldugu kadar compackt tutmaya çalışıyorlar tabi burada kayıtlar milyonlarla ifade ediliyor plc den veri okuyup yazan bir uygulama. Demem oki her yiğidin bir yoğurt yiyişi vardır. A.E.O.

[thelvaci]

Sizlere detaylı malümat vermek isterdim ama hem buna ayıracak bolca vaktim yok hem de kendimi bir DBA yerine koyacak bilgim yok.

Ancak şunları söyleyebilirim ki; genelde veritabanlarının indexleme mekanizmalarının b-tree yapılara göre şekillendirildiği; dolayısı ile index performanslarının tablo içerisindeki alan ve kayıt sayısı ile birebir ilintili olduğunu; yeni açılan yada güncellenen kayıtların leaf(yaprak)'ler üzerindeki arama algoritması'nın performansı ile doğrudan ilgili olduğunu; veritabanlarının pek çoğunda bulunan istatistik kavramının veri çekme hızına inanılmaz ekileri olduğunu; Sql Server'da bunu veritabanı ve sunucu özellikleri üzerinden değiştirip sonuçlarını gözlemleyebileceğinizi; 1.000 kayıt ile 100.000 kayıt arasındaki query optimizasyonlarının ve execution planlarının istatistik durumlarının güncelliğine göre ne şekilde değiştiğini inanın izah etmeye zamanım yok.

Arzu eden baksın, hatalı bir kelamım var ise bu durumda paylaşırsanız ben de gözlemlerinizden istifade etmekten memnuniyet duyarım.

@Freeman35: İyi niyetli yaklaşımınıza teşekkürler, maksadımız kalp kırmak, insanları uzaklaştırmak değil. Doğru bildiklerimizi tecrübelerimiz isikametinde paylaşmak. Darkwood'da kırgınlık olmaz, çiko felipe ceyatone lopez martinez gonzales'ten size druncky duck vasıtası ile selam olsun

[freeman35]

......... çiko felipe ceyatone lopez martinez gonzales'ten size druncky duck vasıtası ile selam olsun

Ve aleyna ve aleyküm selam ve rahmetullahü ve berakatühü

[sabanakman]

Her ne kadar farklı yollar öne sürülse de bütün mesajlar ayrı ayrı okuyup değerlendirmeye alınması gerektiği kanaatindeyim. Bu arada eğer fazla kayıt yoğunluğum olmayacak o yüzden Silindi alanı eklemekte benim için hiç sakınca yok diyen birisi için programda ki, stored procedure lerde ki ve viewlerde ki sorgulara dokunmaya gerek kalmayacak bir tavsiye de benden olsun . Asıl tablonun isminin Tablo olduğunu varsayalım. Bu tabloya Silindi alanı ekleyip ismini de (başka bir isim de olabilir->) TabloTbl olarak değiştirilmeli. Bir de

Kod: Tümünü seç

CREATE VIEW [Tablo]
AS
select * from TabloTbl where ISNULL(Silindi, 0) <> 1

şeklinde de ismi değiştirilmeden önceki ismiyle aynı adlı bir view oluşturulmalı. Böylece Silindi alanına bağlı olarak sadece programda kayıt silme organizasyonunu değiştirmek yeterli olacaktır. Başka hiç bir sorgu, stored procedure ve view gibi ilgili tabloyu kullanan sorgulara dokunmaya gerek kalmayacaktır.

Uyarı : SQL Server üzerinde çalışırken eğer view sorgularda "selec * from ..." gibi bir sorgu ile bütün alanlar kullanırsa ve daha sonra bu alanlarda değişikliklik yapılırsa, bu türden tüm viewların tekrar derlenmesi gerekmektedir.

Kod: Tümünü seç

ALTER VIEW [dbo].[Sifre]
AS
select * from ...

Alan değişikliği durumunda sıkıntı yaşamamak için * yerine tek tek alan isimleri yazılabilir ama bu sefer de ilgili viewlar için ilgili alan değişikliği yapılması gerekebilir. İyi çalışmalar.