veritabanı etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
veritabanı etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

05 Aralık 2008

Sql Server 2008 Programlama Yenilikleri

Nedense database yönetim sistemlerinin yeni versiyonları çıktığında bizde çok heyecan yaratmıyor. Nedeni de çok az yeni özellikle gelmeleri. Bunun nedeni ilişkisel veritabanı kavramının yaygın olması sebebiyle yeni özellikten ziyade varolan servislerde performans artışına odaklanılması. Bu sebeple de her yeni versiyonda yüzde olarak performans kazançları belirtilir. Sql Server 2008'de de çok yeni özellik olmasa da ben özellikle veritabanı programlama ile ilgili hoşuma giden birkaç küçük yeniliği yazmak istiyorum.

* Değişken tanımlama
Benim çok canımı sıkan bir durumdu bu. Önce değişkeni tanımlayıp, sonra başlangıç değerini atamak zorunda olmak.

Declare @userid int
Set @userid=999

Geç de olsa bu özellik eklenmiş

Declare @userid=999

* Toplu insert
Daha önce bir kolaylık olarak yazdığım toplu insert konusu union cümlesine gerek kalmadan çözülmüş

insert into user(firstName,lastName,status)
select "Ali","Yazar",1 union all
select "Veli","Okur",0 union all
select "Veysel","Bakar",1

şeklindeki ifade

insert into user(firstName,lastName,status)
values
("Ali","Yazar",1),
("Veli","Okur",0),
("Veyseş","Bakar",1)

bu şekilde yazılabiliyor

* Merge

İki tablonuz olduğunu düşünün. Biri gerçek kullanıcılarınızın olduğu "user" tablosu, diğeri de herhangi bir kaynaktan topladığınız yeni kullanıcılarınız olan "newUSer" tablosu. Yapmak istediğiniz userid bazında bakıp, olmayanları eklemek, olanların ise bilgilerini güncellemek.

Aşağıdaki cümleyle bu işlem yapılabiliyor

Merge user as u
using newUser as n
on u.userid=n.userid
when not matched by target then
insert(firstName,lastName,status)
when matched then
update set
firstName=n.firstName,
lastName=n.lastName,
status=n.status

* Grouplama Setleri
Bu özellikle de birden fazla gruplama alanına göre sonuçlar aynı select cümlesi içinde toplanmış. Msdn sitesindeki örnek bu ihtiyaç için çok uygun olduğu için direk aynısını kullandım.

Select Region,Country,Store,SalePerson,Sum(TotalDue) as TotalSales
from SalesData
group by grouping sets
(
(Region,Country,Store,SalesPerson),
(Region,Country),
(Country),
(Region)
()
)

şeklinde yazılan sorgu sonucu aşağıda şekilde listelenir



Daha fazla bilgiye buradan ulaşabilirsiniz.

02 Temmuz 2008

Sql Server 2005 Kullanıcı ve Login Eşleşmesi

Sql Server 2005, veritabanı backup setini restore ettikten sonra, veritabanında varolan kullanıcıyı sql server logini olarak yaratıp bunu veritabanına kullanıcı olarak eklememize izin vermez. İzin vermediği gibi bu veritabanı kullanıcısını silemeyiz de. Problem bu kullanıcının en az bir şemanın sahibi olmasından kaynaklanır.

İlk çözüm olarak ilgili şemanın sahibini silmek istediğimiz dışında bir kullanıcı yaptığımızda, kullanıcıyı silebiliriz.

Fakat bugün bu işlemin daha kolay bir yönetemine rastladım. sp_change_users_login isimli sp yardımıyla veritabanı kullanıcımızı sql server login ine bağlayabiliriz.

EXEC sp_change_users_login 'Update_One', '@LoginName', '@UserName';

31 Aralık 2007

2007'nin Bıraktıkları

Blog okuyanlar mutlaka yaşamıştır. Tesadüfen bir kaç ay önce yazılmış gündemle alakalı bir yazıya rastlarsınız. Yazı derinlemesine yazılmış ve onlarca yorum yapılmıştır. Konunun sıcaklığı geçip bir de aradaki geçen zamanın olgunluğu eklendiğinde yorumlar biraz daha duru bir şekilde olur. Ama blogların dinamikleri itibariyle o kadar eski bir yazıya yorum yapamazsınız. Ama insan kendi yazdığı yazıya yorumlar ve eklemeler yapabilir galiba :) Ben de bu kategoriye giren bir kaç yazı seçtim bir kaç küçük ekleme yapmak istedim.

Veritabanı ve Pazarlama
İnternetin pazarlama faaliyetlerinde kullanılmaya başlanmasının ülkemiz için yeni olduğunu söyleyebiliriz. Bilgi toplama konusunda zamanla daha doğru düzgün yöntemler kullanılmaya başlanıyor. Ama hala buradaki en ciddi problem bu tarz işlerin teknik olmayan veya yeterli düzeyde donanıma sahip olmayan kişiler tarafından üstlenilip yönlendirilmesi.

Web 3.0 ve Servis Odaklı Mimari
Burada tekrarlamak istediğim şey, bu standartların bir moda gibi düşünülüp kendi başında değerlendirilmemeleri. Kullanım alanına uygun olarak bu parçalardan doğru olanları uygulamalara yerleştirmemiz.

Web 3.0 yazılımcısı olmak
Artık kaliteli uygulamalar için web platformunda web yazılımcılarının değil daha nitelikli yazılımcıların çalışması gerektiğinden bahsetmiştim. Aslında o günlerde piyasada nitelikli yazılımcı bulmanın zorlaştığı bir döneme girdik. Böyle bir ortamda bu ne kadar mümkün olacak tartışılır.

Programlanabilir Web
Google'ın Open Social ile Facebook un karşısındaki gövde gösterisi Türkiye için kayda değer bir sonuç vermedi aslında. Facebook için geliştirilen uygulamalar hızla artıyor. Zamanla artık ayakta kalabilen saman alevi gibi olmayan uygulamarın daha revaçta olacağını düşünüyorum. Ama bunun da ne kadar süreceğini yine bekleyip göreceğiz.

Herkese mutlu yıllar :)

11 Aralık 2007

Veritabanı İsimlendirme Kuralları

Kod yazma standartlarında bazı isimlendirme notasyonları kullanılmaktadır. Database nesneleri için de bazı standartlar önerilmekte. Aşağıda bu standartları derleyip kendi yorumlarıma göre değiştirerek bir kaç madde listelemeye çalıştım. İsimlendirmede genel olarak Pascal Case kullanılmaktadır.

Tablo isimlendirmesi:
  • Tablo isimleri çoğul olmalıdır şeklinde bir kural var. Fakat çift kelimeli tablolar kullandığımızda bir sıralama problemi yaşamamız mümkün. Yani Users ve UserAnswers şeklinde bir sıralamada UserAnswers daha önde olur. Bu yüzden şahsi görüşüm temel tabloları tekil olarak isimlendirmenin daha doğru olduğu yönünde.
  • Birden fazla kelimeli tablo isimlerinde sadece son kelime çoğul olmalıdır. Örneğin UserAnswers.
  • tbl gibi bir prefix hiç bir anlam ifade etmediği için kullanılmamalıdır. Prefix olarak projenin kısaltılması kullanılabilir. Örneğin Google Analytics projesi için GaUser şeklinde bir isimlendirme olabilir.
  • Tablo isimlerinde _ kullanılmamalıdır
  • SQL cümlelerinde SQL terimlerinin tamamı büyük harfle kullanılmalıdır
  • Developer dışında kişilerin de database i kullanma ihtiyacı olacağı için hiç bir kısaltma kullanılmamalıdır
  • Çoka çok ilişkilerde iki tablo ismi de çoğul kullanılması önerilir. Ama son kelimenin çoğul kullanılma kuralı ile karmaşa yaratacağı için bu durumda da son kelimeyi çoğul olarak kullanmak daha tutarlı olacaktır. Örneğin EmployeeCustomers



Kolon isimlendirmesi

  • User tablosu için UserId alanı key alan için kullanılabilir. Fakat SQL Server'da I küçük harfle i nin karşılığı olmadığı için dilimize özgü olarak tüm Id ifadelerinin id olarak yazılmasını öneriyorum. Örneğin Userid,Cityid.
  • Yabancı anahtarların isimleri ana tablodaki alan isimleriyle aynı olmalı. Örneğin City tablosunda alan Cityid olarak kullanıldıysa id değerin tutulduğu User tablosunda da Cityid olarak kullanılmalıdır.
  • Birden fazla alanın PK olduğu tablolarda id isiminde bir alan kullanılmamalıdır.
  • Kolon isminde kln, fld gibi prefixler kullanmak gereksizdir. Sadece alan IntUserid şeklinde alan tipi prefix olabilir ama bu da pek önerilen bir şey değildir.
View isimlendirmesi
  • Vw prefix iyle başlamalıdır.
  • İki tablo join edilerek bir view oluşturuluyorsa isimde iki tablo da kullanılmalıdır.
SP isimlendirmesi
  • Create,Get,Update,Delete,Set gibi fiil ifadeler isimde prefix olarak kullanılabilir. Örneğin GetUserInformation.
  • "sp_", "xp_" veya "dt_" gibi prefixler kullanıldığında önce master tabloya bakılıp aranacağı için bir performans kaybı yaratır. Kesinlikle kullanılmamalıdır.

28 Ekim 2007

Assocıatıve (Çağrısımsal) Model Database

Web 3.0 'ın mimari anlamındaki yaklaşım değişikliğinden ve semantic web kavramının merkezine yerleşmesinden bahsetmiştim. Bir database mimarı veya tasarımcısının web 3.0 ile birlikte bir takım değişikliklere maruz kalması muhtemel. Veritabanı sistemlerinde köklü bir değişliklik olan ilişkisel veritabanı tasarımının yerini web 3.0 da associative (çağrışımsal) model tasarıma kısmen bırakabileceğini söyleyebiliriz.

Aslında ilişkisel veritabanı modelinin daha katı kuralları olan ve net veriler söyleyen bir model olduğunu söyleyebiliriz. Semantic web in doğası da aslında metadataya (veri hakkında veri) dayanmakta. Yani herşeyin siyah ve beyaz olmayıp gri tonların değerlendirilmesi; bir nevi bulantık mantık yaklaşımı.

Bir giriş niteliğinde fikir oluşması açısından Mike Griffiths 'in 2001 yılında yazdığı makaledeki örnekler üzerinde duracağım.




Verilerimiz aşağıdaki cümleler olsun.

"Red is a Colour"
"Mary is a Vegetarian"
"Vegetarians eat Plants"
"Cardiff is located in Wales"
"Wales is part of the UK"

Bu verileri ilişkisel bir veritabanında tutmak isteseydik çeşitli unsur tablolarına ve özelliklerinin tutulacağı ilişkisel tablolara ihtiyaç duyacaktık. Ama 5 cümlenin de birbirinden alakasız fiil ve özellikler içermesi sebebiyle ilişkisel model bir hayli zahmetli olacaktı.

Associative model kullanarak bu cümleleri saklamak istediğimizde 2 tabloya ihtiyacımız olacak. İlki nesne, fiil ve özelliklerin saklandığı Items tablosu, İkincisi ise bu item ların ilişkilerinin tutulduğu Links tablosu

Items

Items (1. tablo)

Identifier Name (Tablo alanları)
12 Red
41 Is a
76 Colour
14 Mary
81 Vegetarian
43 Eats
82 Plants
15 Ski Lessons
39 Start at
83 08:00
42 On
85 Sunday


Links (2. tablo)

Identifier Source Verb Target (Tablo alanları)
101 12 41 76
103 14 41 81
124 81 43 82
105 15 39 83
107 105 42 85

Burada göze çarpan en önemli nokta link tablosundaki bir elemanın farklı bir elaman içerinde bir kaynak olarak kullanılabilmesi. Verileri dikkatli bir şekilde incelediğinizde sanırım bu model hakkında bir miktar fikir sahibi olacaksınız.

Note:This picture has been taken from flickr.

24 Eylül 2007

And Operatörü ile Sorgulama

Veritabanı sorgulamalarında and ifadelerine sahip cümle grubunda 1. şartın sağlanmaması durumunda diğer şartlar kontrol edilmez. Bu durumda and ifadesi öğelerinde en hızlı çalışacak koşulu önce yazmak bize performans kazancı sağlayacaktır.

Örnek verecek olursak;

Bazı durumlarda bir değerin bulunan kayıta göre iki farklı alandan alındığı durumlar olabilmekte. Örneğin müşteri tablomuzda name,surname ve firmname isimli alanlar olsun.
Name ve surname alanları boşsa müşteri ismi firmname kolonundan alınsın.

Eğer biz A ile başlayan müşterileri sorgulamak istersek;

(name like 'A%' and firmname is null) or (firmname like 'A%' and name is null)

şeklinde yazabildiğimiz sorguyu ;

(firmname is null and name like 'A%' ) or (name is null and firmname like 'A%')

şeklinde yazarsak daha performanslı çalışır. Performans kazancı koşulların çok olduğu cümlelerde artacaktır.

11 Temmuz 2007

Veritabanı ve Pazarlama

Amazon ve eBay etkin veritabanı kullanarak nasıl birer deve dönüşmüştür? Aslında Amazon basit anlamda müşterilerinin satış bilgilerini kullanarak yeni satışlar için çeşitli yönelimler sunmuştur. Peki CRM yaklaşımında kullanılan müşteri veritabanı nasıl oluşur?
Ana sınıflandırma olarak hayatın doğal akışıyla oluşan veriler ve özel olarak alınan veriler olarak iki tip veriden bahsedebiliriz. Örneğin Turkcell için benim yaptığım tüm aramaların numaraları, konuşma süreleri,tercih ettiğim saatler, mesaj çekme yoğunluğum, hangi şebekeleri kullandığım doğal akışımda oluşan bilgilerdir. Hat almak için doldurduğum sözleşmedeki bilgilerse 2. kategoridedir. Aynı şekilde marketten aldığım ürünler de doğal akışla oluşan veriler. Başka bir gruplamayı da kişilerin özlük bilgileri, tercihleri ve aktiviteleri olarak tanımlayabiliriz. Bu gruplamada bazı durumlarda aktivite tercihler hakkında bilgi sahibi verebilir.
Veritabanı kullanım şeklini de 3 seviyede ele alabiliriz. Birincisi klasik anlamda bazı işlemleri yapabilmek için veri depolamak anlamında kullanılan veritabanı. Örneğin giriş yapan kullanıcının şifre kontrolü için şifre bilgisini kaydetmek.İkincisi raporlama ve analiz amaçlı bazı verileri depolamak.Üçüncüsü ve en önemlisi ise bu verilerin işlenerek stratejik kararlarda destek niteliğinde kullanılması.
Bu durumlar için en güzel örnek Google Analytics aracı olacaktır. Bir kaç yıl öncesine kadar sitelere konulan sayaçlar belki de sitenin istatistik ihtiyacını gideriyordu, fakat günümüzde tarih, saat, lokasyon, sitede kalma süresi, internete bağlandığı ağ, tarayıcı tipi, javascript desteğinin olup olmadığı, arama motorlarından geldiyse hangi kelimelerle arandığı gibi çok sayıda veri alınıyor.
Peki bu yöntemle elimizde çok değerli! bilgiler oluştu. Bu bilgileri saklayabilmek için veri depolama maliyetlerimiz arttı. Veri çoğaldığı için yorumlamak daha da zorlaştı. Kritik olan nokta bu verilerin ne kadarını kullandık. Attığımız taş ürküttüğümüz kurbağaya değdi mi?

Bir kaç önemli kuralı sıralayacak olursak;
* Esnek bir veritabanı tasarımı yapılıp bu tasarıma göre veri alınmalıdır.
* Her veri önemli değildir. Bilgiye dönüşmeyen verinin bir faydası yoktur.
* Veri alındığı anda değerlidir. Bir süre sonra veri önemini kaybeder.
* İnsanlar bilgi vermekten hoşlanmıyor veya isteksiz veriyor.

Çehov'un "Duvarda asili silah oyunun sonunda mutlaka patlar" kuralına gönderme yaparak "veri alındıysa mutlaka değerlendirilmelidir" dersek çok katı olmayız sanırım :)