Web programlamanın yavaş yavaş var olmaya başladığı zamanlardı.

Daha bıyıklarımın yeni terlemiş olmasına bile bakmadan “acaba kendim bir şeyler yapabilir miyim” düşüncesiyle birkaç kişinin kapısını çalıp “ben kurum ihtiyaçlarınız doğrultusunda web üzerinde istediğiniz geliştirmeleri yapabilirim” demeye başladım. Amacım erken ötmekti yani…

Erken öttüm, erken sustum…

Niye mi?

Bir müşteri toplantısında ben hazırladığım sunumları, verebileceğim hizmetleri çantamdan çıkarıp anlatmaya başlarken şu soruya maruz kaldım da ondan;

-          “Sen şimdi kaça yapıyosun bi siteyi?”

-          !!!!????!!!!!???

99 depremi ve Veli Göçer’in siteleri aklıma gelmişti bu “site”den. Meslekten soğumamak adına sustum, teşekkür edip çıktım ve bordrolu hayatı seçtim.

*** Devamını Oku… »

“Doğrudan Pazarlama” denince benim anladığım, müşteri bilgilerinin takip edildiği, kayıtlandığı, sorgulandığı ve ‘değer’ haline getirildiği sistemler, ürünler yapmak. Dolayısıyla doğrudan pazarlama iletişiminde  müşteri verilerinin saklanması, güvenliğinin sağlanması, veri sisteminin esnek sorgulama isteklerine cevap verebilmesi, yedeklenmesi ve nihayetinde değer kümesi haline getirilmesi gibi bir dizi ihtiyaç beliriyor. Bu ihtiyaçların giderildiği alan da haliyle Bilgi Teknolojileri.

Bu ilk buluşmada veritabanı kurgusu üzerine yazmak istiyorum, yani aslında projenin IT kurgusu. Veritabanı, IT tarafının doğrudan pazarlamaya sağlayacağı katkının sadece bir aşaması belki, ama sanırım en önemlisi…

Excel’den tutun Teradata sistemlerine kadar geniş bir yelpazedeki ürünleri “Veritabanı” olarak isimlendirebiliriz. Elimizdeki müşteri verilerinin büyüklüğü ve içeriğine göre hangisini kullanacağımıza karar vermemiz gerekiyor. Bu aşamada veriyi teknik olarak iyi analiz etmemiz lazım. İdealde bu işi SQL Server veya Oracle’a bırakmak en iyisi. Ancak işler karmaşıklaştıkça, işin içine on yıllara yayılan satış bilgileri, hangi müşterinin ne zaman hangi mağazadan hangi ürünü ne kadar aldığı gibi detaylar girdikçe Teradata’ya doğru yeşil ışık yakmak gerekebilir.

Bu aşamada veritabanı server’ını da belirlemek gerekiyor. Yine verilerin büyüklüğü ve yapısı seçimi belirleyen kriterler. Server’ın 20-24 derece ısıdaki bir odada, kilitli bir dolap içinde bulunması gibi olmazsa olmazları yine de yazalım. Aynı odada bazen insanların tüm mesailerini geçirdiklerini de gördüm. Konudan kopmadan bu durumu da protesto ettiğimi belirtmeliyim. Büyük firmalara yakışmıyor. Temmuz ayında mantoyla oturan personelden alınan verim düşebilir. Server performansını arttıralım derken…

Server seçimi sırasında bir sistem mühendisi ile beraber çalışmak doğru, ama sadece sistem mühendisiyle değil. İşin akışıyla ilgili bilgiler bu aşamada mutlaka paylaşılmalı…

Devam edelim…

Veriler her türlü analize cevap verebilecek şekilde depolanmalı. Mesela ad ve soyadı tek bir alanda tutmak yetersiz kalabilir. Soyadı “Sağlam” olanlara kampanya yapmak isteyebilirsiniz çünkü. Aklınıza gelebilecek her bilgiyi ayrı alanlarda hatta bazen ayrı tablolarda tutmak, sistemin esnekliği adına çok mühim. Veritabanı kurulumu yapılırken bile bu bilgilere göre hareket etmek gerekecek. Bu konuyla ilgili enteresan senaryolara ileriki yazılarda değinebiliriz. Çok tablodan korkmamak lazım, açabildiğimiz kadar açabiliriz, yeter ki mantık silsilesine aykırı olmasın.

Her veri tablosunu oluşturmadan önce çeşitli öngörüler geliştirmeliyiz. “Bu mağazanın yıllık satışı ne kadar?”, “Günde kaç müşteri geliyor?” gibi soruların cevapları olmalı. Buna göre açacağımız tablonun ortalama 1 yılda kaç kayıt barındıracağı belli olur, tablo ayarlarını buna göre yapmak hem performans hem de güvenlik açısından elimizi rahatlatır. Bir gün her şey yolunda giderken “Tablo şişmiş” sözüyle başlayan kara saatleri genelde bu konudaki başta yaptığımız (daha doğrusu yapmadığımız) kurgulamadan yaşarız. Öngörü kuşkusuz ki sadece kayıt sayısından ibaret değil, bu sadece bir örnek.

Unutmamak lazım ki yapılan projelerin teknik riskleri genelde ilk baştaki kurgulamadan doğar. Sadece merminin bizi vurması uzun sürer.

Yedek, yedek, yedek…

Evet çok mühim… Veriler yedeklenmeli. Ama nasıl? Çok detaya girmeden anlatmalıyım.

Veritabanının günlük full backup’ları kendi üzerine alınmalı.

Bitti mi? Bitmedi…

Bu backup dosyası network içindeki bu işe ayrılmış ayrı bir server’a da kopyalanmalı.

Bitti mi? Bitmedi…

Backup tape’e de alınmalı.

Bitti mi? Bitmedi…

Aynı zamanda alınan backup dosyası yine bu iş için ayrılan ayrı bir backup server’a restore edilmelidir. Ani geri dönüşler ve alınan backup’ın hemen açılıp açılamayacağı sorularına cevap vermesi bakımından bu çok önemli.

Transaction backup’ları ise yine projenin yapısına göre her dakika başında da olabilir, 6 saatte bir de… Akla ilk gelen örnek; “kredi kartlı satış yapıyorsanız transactional backup periyodu sık olmalı”. Peki ne kadar sık?  İşte inisiyatif zamanı…

Bu yazının içine güvenlik adına da bazı cümleler girmeliydi.  Ancak güvenlik konusunu diğer yazılarımda ayrıca ele alacağım.

Şimdilik sadece “İyi kurgu” diyelim… İlk aşama bu… En önemli aşama…