Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 5/5 - 2 oy
  • 1
  • 2
  • 3
  • 4
  • 5
MS-SQL Server Procedure Tavsiyeleriniz
#11
GUID bildiğim kadarı ile (yanlış biliyor olabilirim) RDBMS lerde ilk kayıt anında programıcının da (normal olarak) göremeyeceği şekilde oluşturulan 32 byte lık bir alan. Eğer ben bir VT yazsa idim muhtemelen öyle bir alan koyardım (silinen kaydı geri getirmek için mesela). Banada saçma geliyor öyle bir alan kullanmak, en azından Tuğrul beyin dediği gibi 4 byte int alan varken (proje küçük dahi olsa) neden 32 byte alan ayırayım ki? Bunun yanında @meko nun bahsettiği amaçla kullanılabilir ki ben yazsam yinede o şekilde kullanmazdım, onun yerine mümkün olan en küçük byte alanı kaplıcak rakamsal bir tip kullanırdım ki sorgular daha hızlı çalışsın.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#12
Tuğrul bey bize bahsedecek pek bir şey bırakmamış gibi...  Smile

Benim de konuya katkım şöyle olsun; Kullanıcı adı ve şifre kontrolü yapılacaksa büyük / küçük harf duyarlılığının da etkin hale getirilmesi gerekir. Onu da SELECT'e kriter tanımlarken COLLATE (harmanlama) yan tümcesini kullanarak yapıyoruz. Bazen kayıt aşamasında kullanıcının birebir yazdığı gibi veriyi aramak gerekir, bazen de güvenliğin değilde, içeriğin önemli olduğu durumlarda büyük - küçük harf duyarlılığını göz ardı etmemiz gerekir.

CREATE  PROCEDURE dbo.Kullanici_Dogrula
        @KulaniciAdi NVARCHAR(20)
      , @Sifre       NVARCHAR(20)
AS  BEGIN
   SET NOCOUNT ON;
   DECLARE @PersonelId INT = ISNULL( ( SELECT  TOP 1
                                               ID                                        --> CI = Case insensitive > Büyük/Küçük harf duyarsız
                                       FROM    dbo.PERSONEL                              --> CS = Case Sensitive   > Büyük/Küçük harf duyarlı
                                       WHERE   KULLANICI_ADI = @KulaniciAdi  COLLATE TURKISH_CS_AS  --> yada hangi alfabeyi istiyorsanız...
                                         AND   SIFRE         = @Sifre        COLLATE TURKISH_CS_AS  --> yada hangi alfabeyi istiyorsanız...
                                      )
                                   , 0)  --> -1 --> Tercih bu yönde ise
   IF (@PersonelId > 0)  BEGIN           --> -1 isteniyor ise --> ( @PersonelId >= 0 )
       UPDATE TOP (1)  --> burası önemli, sadece tek kayıt güncelleyeceğimizi ifade ediyoruz...
                      dbo.PERSONEL
       SET            SON_GIRIS  =  GETDATE()
       WHERE          ID         =  @PersonelId
       ;
   END ELSE BEGIN
       RAISERROR(N'Belirttiğiniz kullanıcı adı (%s) veya şifresi yanlış.', 16, 1, @KulaniciAdi); --> Tek başına bu haliyle de akışı bozmaz, sadece mesajı verir ve devam eder...
   END
   SELECT @PersonelId as ID;
END
GO
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#13
GUID 16 byte'mış:
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
There's no place like 127.0.0.1
WWW
Cevapla
#14
(24-07-2017, Saat: 22:59)uparlayan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlTuğrul bey bize bahsedecek pek bir şey bırakmamış gibi...  Smile

Benim de konuya katkım şöyle olsun; Kullanıcı adı ve şifre kontrolü yapılacaksa büyük / küçük harf duyarlılığının da etkin hale getirilmesi gerekir. Onu da SELECT'e kriter tanımlarken COLLATE (harmanlama) yan tümcesini kullanarak yapıyoruz. Bazen kayıt aşamasında kullanıcının birebir yazdığı gibi veriyi aramak gerekir, bazen de güvenliğin değilde, içeriğin önemli olduğu durumlarda büyük - küçük harf duyarlılığını göz ardı etmemiz gerekir.

CREATE  PROCEDURE dbo.Kullanici_Dogrula
        @KulaniciAdi NVARCHAR(20)
      , @Sifre       NVARCHAR(20)
AS  BEGIN
   SET NOCOUNT ON;
   DECLARE @PersonelId INT = ISNULL( ( SELECT  TOP 1
                                               ID                                        --> CI = Case insensitive > Büyük/Küçük harf duyarsız
                                       FROM    dbo.PERSONEL                              --> CS = Case Sensitive   > Büyük/Küçük harf duyarlı
                                       WHERE   KULLANICI_ADI = @KulaniciAdi  COLLATE TURKISH_CS_AS  --> yada hangi alfabeyi istiyorsanız...
                                         AND   SIFRE         = @Sifre        COLLATE TURKISH_CS_AS  --> yada hangi alfabeyi istiyorsanız...
                                      )
                                   , 0)  --> -1 --> Tercih bu yönde ise
   IF (@PersonelId > 0)  BEGIN           --> -1 isteniyor ise --> ( @PersonelId >= 0 )
       UPDATE TOP (1)  --> burası önemli, sadece tek kayıt güncelleyeceğimizi ifade ediyoruz...
                      dbo.PERSONEL
       SET            SON_GIRIS  =  GETDATE()
       WHERE          ID         =  @PersonelId
       ;
   END ELSE BEGIN
       RAISERROR(N'Belirttiğiniz kullanıcı adı (%s) veya şifresi yanlış.', 16, 1, @KulaniciAdi); --> Tek başına bu haliyle de akışı bozmaz, sadece mesajı verir ve devam eder...
   END
   SELECT @PersonelId as ID;
END
GO

Merhaba,
Tuğrul hocamın paylaşmış olduğu method işimi fazlasıyla çözdü. Kendisine bir kez daha teşekkür ederim.
Uğur Bey göz ardı ettiğim bir kısma sağlamış olduğunuz katkıdan dolayı teşekkür ederim.
Metodu bu şekilde güncelliyorum.
While true do; Hayat döngüsü, kısır değildir! Yapılan bir yanlış, o döngünün dışına çıkmanızı sağlayacaktır.
WWW
Cevapla
#15
Ben sistemin de hem GUID hemde AutoINC kullanıyorum. Müşterilerimiz bazen ilk etapta local lisans satın alıp daha sonra biz server lisansı istiyoruz diyebiliyorlar. Bu durumda da birden fazla veritabanını tek veritabanında birleştirmek gerekebiliyor. AutoINC çakışmalarını önlemek ve aktarım kolaylığından ötürü GUID çok başarılı tek eksi tarafı "IN" kullanımında performans yerlerde sürünüyor..
Amatör Küme Bilgisayar Programcısı
WWW
Cevapla
#16
Ek olarak belirtmek isterim. COLLATE kullanırken dikkatli olmalısınız. COLLATE kullandığınız alan index'li bir alan ise, performans kaybı yaşayacaksınız demektir. Indexli alanlar üzerinde yaygın olarak kullanılan 2 çeşit arama vardır. Birincisi Seek, ikincisi Scan. Seek sıralanmış bir veri kümesi üzerinde hızlıca konumlanma sağlarken, Scan her daim kayıtları dolaşarak arama işlemi yapar. İşte index'li bir alan üzerinde COLLATE kullanımı Index Seek yapılmasına mani olur ve Index Scan metodu kullanılır. Bu da performans sıkıntısı yaşatabilir. Sözün özü; sadece gerçekten gerek olduğuna inanıyorsanız COLLATE kullanmanızı öneririm.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#17
(25-07-2017, Saat: 14:54)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlEk olarak belirtmek isterim. COLLATE kullanırken dikkatli olmalısınız. COLLATE kullandığınız alan index'li bir alan ise, performans kaybı yaşayacaksınız demektir. Indexli alanlar üzerinde yaygın olarak kullanılan 2 çeşit arama vardır. Birincisi Seek, ikincisi Scan. Seek sıralanmış bir veri kümesi üzerinde hızlıca konumlanma sağlarken, Scan her daim kayıtları dolaşarak arama işlemi yapar. İşte index'li bir alan üzerinde COLLATE kullanımı Index Seek yapılmasına mani olur ve Index Scan metodu kullanılır. Bu da performans sıkıntısı yaşatabilir. Sözün özü; sadece gerçekten gerek olduğuna inanıyorsanız COLLATE kullanmanızı öneririm.

Bu konu önemli, o nedenle bu sorunun çözümünü bir makale ile anlatacağım
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#18
(25-07-2017, Saat: 14:54)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlEk olarak belirtmek isterim. COLLATE kullanırken dikkatli olmalısınız. COLLATE kullandığınız alan index'li bir alan ise, performans kaybı yaşayacaksınız demektir. Indexli alanlar üzerinde yaygın olarak kullanılan 2 çeşit arama vardır. Birincisi Seek, ikincisi Scan. Seek sıralanmış bir veri kümesi üzerinde hızlıca konumlanma sağlarken, Scan her daim kayıtları dolaşarak arama işlemi yapar. İşte index'li bir alan üzerinde COLLATE kullanımı Index Seek yapılmasına mani olur ve Index Scan metodu kullanılır. Bu da performans sıkıntısı yaşatabilir. Sözün özü; sadece gerçekten gerek olduğuna inanıyorsanız COLLATE kullanmanızı öneririm.

Yanlışsam düzeltin lütfen...

Zaten her string (varchar, nvarchar, text ntext vs) alanın bir COLLATE'i (ENGLISH, TURKISH vb.) vardır. Bir veritabanında bir string alana göre arama yapıyorken DB'de tanımlanmış orijinal COLLATE 'i dışında farklı bir COLLATE ile aramaya zorlarsak (ki arkdaş öyle yapmış) dediğiniz durum oluşur. Biraz söylediklerinize ek gibi oldu.

(21-07-2017, Saat: 18:39)esistem Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlGUID bildiğim kadarı ile (yanlış biliyor olabilirim) RDBMS lerde ilk kayıt anında programıcının da (normal olarak) göremeyeceği şekilde oluşturulan 32 byte lık bir alan. Eğer ben bir VT yazsa idim muhtemelen öyle bir alan koyardım (silinen kaydı geri getirmek için mesela). Banada saçma geliyor öyle bir alan kullanmak, en azından Tuğrul beyin dediği gibi 4 byte int alan varken (proje küçük dahi olsa) neden 32 byte alan ayırayım ki? Bunun yanında @meko nun bahsettiği amaçla kullanılabilir ki ben yazsam yinede o şekilde kullanmazdım, onun yerine mümkün olan en küçük byte alanı kaplıcak rakamsal bir tip kullanırdım ki sorgular daha hızlı çalışsın.

GUID kullanmak özellikle dağıtık ortamlarda replication amaçlı çok faydalıdır. Zaten son zamanlarda yaygınlaşmasının sebebi de budur. Eskiden firmalar müstakil (tek başına) çalışırken artık bir çok firma şubelerini, bayilerini veya sahadaki elemanlarını (mobil cihazlar yoluyla) sisteme entegre etmek istemektedir. Sanırım GUID lere olan ihtiyaç bundan artmıştır.

Bir yanlışı düzeltmek istiyorum. GUID string bir veri değildir. 16 byte uzunluğunda integer bir veridir. 4 byte lık Integer veri türüne göre elbette indekslenmesi daha zordur ama yine de ihtiyaç duyduğumuz alanlarda kabul edilebilir bir konfor sağlamaktadır. GUID ile ilgili bir derleme yaptım:

Primary Key'i GUID kullanmanın avantajları:

1. Offline olarak key üretebilirsiniz. Yabi merkez veritabanına bağlı olmadan primary key üretebilir ve sonra bu verileri merkez sunucuya atabilirsiniz.
2. Daha sonra kendi veritabanınızı başka bir veritabanı ile birleştirmek isterseniz sorun yaşamazsınız.
3. Faydaları hakkında tüm yazılan şeyler replication ve database birleştirme ile ilgili...

GUID kullanmanın dezavantajları:

1. Daha çok yer kaplar. (Son zamanlarda HDD'ler çok büyüdüğü için bunun sorun teşkil ettiğini düşünmüyorum.)
2. Indexleme daha yavaş olur. (Test: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol) (Test2: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol)
2. Uygulamayı DEBUG ederken zor olur.
3. Kayıtları giriş sırasına göre listeleyemezsiniz. Ama bir çok dil bizlere zamana bağlı sıralı GUID (sequential GUID) üretme imkanı vermektedir. MS SQL Server 2005 ve sonraki sürümlerde newsequentialid() fonksiyonu vardır.
WWW
Cevapla
#19
Çözümü basit, tablo tasarımında COLLATE tanımına dikkat edilecek, olay bu...

Açacak olursak COLLATE ve INDEX arasındaki performans problemine sebep olan şey, seek ve scan yöntemlerininin belirlenmesine neden olan ana unsur SELECT sırasında farklı bir COLLATE kullanmaya çalışmaktır, bunun sonucu olarak SQL Server arka tarafta örtülü optimizasyonlar nedeniyle tür dönüşümü yapar, dolayısıyla tür dönüşümüne düşmemek için de en temel çözüm tablo tasarımı sırasında ilgili alanın kullanımına uyacak bir COLLATE seçmekten geçer.

Makale yazacağımdan bahsetmiştim ama aşağıdaki linkte bu durumla nasıl baş edileceğine dair bilgiler veren bir çalışma zaten yapılmış;

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol # Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#20
Ekleme ve düzeltme yapan tüm arkadaşlarımıza teşekkür ederim.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter



Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Sql Server Otomatik Kurulum narkotik 7 151 13-01-2018, Saat: 22:30
Son Yorum: narkotik
  Raporlamada hangisi daha performanslıdır View? Store Procedure? adelphiforumz 13 363 23-12-2017, Saat: 22:09
Son Yorum: FiRewaLL
  SQL Server veritabanını Suspect & Emergency modundan kurtarmak Abdullah ILGAZ 2 181 23-12-2017, Saat: 08:52
Son Yorum: Abdullah ILGAZ
  SQL Server - Client Güncelleme CaglarCoskun 10 432 14-08-2017, Saat: 11:06
Son Yorum: uparlayan
  SQL Server Numarator CaglarCoskun 5 398 05-08-2017, Saat: 15:20
Son Yorum: CaglarCoskun



Konuyu Okuyanlar: 1 Ziyaretçi