Oracle'da Kolondaki Data Formatlarını Bulmak

Merhaba Arkadaşlar,

Oracle'da bir kolonunuz var diyelim ki. Best practice olarak kolonu data tipi, gerekirse validasyonlarla kontrol edebiliriz. Ancak bazen dba'lerin önem vermemesi ya da uygulama operasyonlarının ilgisizliği veyahut ilgili analist/geliştiricinin kötü tasarımı/geliştirmesi ile(bazen de hızlı canlıya çıkma ihtiyacının bir sonucu olarak) bazı alanlarda bozuk formatlarda data girilebilir.

Bizim ihtiyacımız da bu formatları bulmak ve düzenlemek idi. Örneğin müşteri numarası ya da telefon numarası gibi nümerik bir alan girişi olduğunu düşünün. Tüm formatları nasıl bulurdunuz?

Şöyle yapabiliriz, ki muhtemelen daha güzel çözümler vardır, tüm sayıları 0'a çevirip, öncelikle sayıları eşitledik. Sonra da distinct kolonu çektik. Böylece kaç tipte data var görmüş oluruz.

select distinct

replace(

replace(

replace(

replace(

replace(

replace(

replace(

replace(replace(a.TelNo,9,0),8,0),7,0),6,0),5,0),4,0),3,0),2,0),1,0) as alan

from gurkan_tablo_yedek a 

Örneğin şöyle sonuçlar dönebilir:

00/000/-000-00

00/000/-000000

00/000/00000/00

00/000/000000

00/000/00

0/000/0000000

0000000000

00/0000000000

00/000/000000/00

Hepsini sıfıra çevirme nedenim de, sonuçlardan göreceğimiz üzere, her bir sayı için farklı sonuç gelmemesi içindi.

Sonra görüşürüz.

Toad: SQL Loader ile Toplu Veri Aktarımı

Selam Arkadaşlar,

Bugün size Toad içindeki güzel bir internal tool'dan bahsedeceğim: SQL Loader.
Kullananlar vardır eminim ama çok yaygın olmadığından ve benim gibi daha önce kullanmamış olanlar için kısaca bahsetmek istiyorum. Elinizde onbinlerce kayıt olan bir döküman var ve bunu veritabanında bir tabloya yazmak istiyorsunuz. Excel'i açıp birkaç saniye içinde insert statement'ı çekebilirsiniz ancak takdir edersiniz ki, bunların db'ye yazılması, kayıt büyüklüğüne de bağlı olarak, saatler alabilir. SQL Loader ile bu işlemi saniyeler içinde yapabiliyoruz. Farklı özelliği var mı bilmiyorum ama sanıyorum import özelliğine istinaden oluşturulmuş bu tool.

Toad'a giriyorsunuz. Database sekmesinden-import-SQL Loader Wizard'ı seçiyorsunuz.
Örneğin datanız excel'de falan ise, csv uzantılı bir dosyaya bunu kopyalayıp kaydedin öncesinde. csv dosyasından okuyabilmekte(txt dosyası açın, bunu csv uzantılı olarak değiştirin).
Akabinde gelen ilk ekrandan build a new control file deyin.
Ardından verinizin kolon sayısına ve ne ile ayrıldığına göre seçeneklerinizi seçin. Benim datam tek kolonlu olunca herhangi bir ayraç seçmeme de gerek kalmamıştı. Sizin çok kolonlu ise, hangi ayraç varsa kolonlarınız arasında, onu seçin.
Akabinde bu datayı hangi tabloya yazacağınızı seçin.(Add diyerek)
Loading Method'u seçmeniz isteyecek. Truncate, insert ve append seçenekleri mevcut. Truncate seçerseniz, önce tablodaki tüm verileri, varsa şayet, uçurur. Daha sonra sizin verdiğiniz datayı yazar.
Insert seçerseniz, içinde data yoksa tabloya yazacaktır, data varsa hata döndürür.
Append seçerseniz de, tabloda data varsa ellemez. Verdiğiniz datayı da ilave eder. Veriyi çoğullama riski yoksa en garanti metot append'dir.
Ancak seçiminizi yapıp add dediğinizde, seçilen metodu kontrol edin. Append seçtiğimde insert, insert seçtiğimde de append bastı ekrana. Toad'ım sapıtmış da olabilir. :)
Datanızda başlık olup olmadığına dikkat edin ve ona göre, hangi satırdan itibaren yazması gerektiğini belirtin.
Sonrasında bir ctf(control file) ismi istiyor sizden. Uydurma bir isim yazın textbox'a. Ne işe yaradığını bilen varsa paylaşabilir.
Son olarak execute now dediğinizde, sadece birkaç saniye içinde, tüm verinin tabloya yazıldığını göreceksiniz.

Görüşmek üzere.

Weblogic - J2EE

Eskiden BEA firmasının olan, Oracle'ın yeni silahı... Application Server'ların arasında en iyisi olarak gösterilmekte. Üzerinde çeşitli uygulamaların çalışmasına olanak veren bir Java uygulamasıdır en basit ifadeyle.

Dışarıdan baktığınızda tek bir process olarak görürsünüz ama içinde birçok uygulama barındırır.
Şimdi önce şu soruyu soralım kendimize: bir bilgiyi kendinde değil de, bir veritabanında tutmak istersem ne olur? Bilgiyi üzerimde tutsam, istek geldiğinde direkt veririm. Ama veritabanındaysa bilgi, birçok teknik detay gerekecek. Yani bir standartizasyon sorunu belirecek. Bu sorunu ortadan kaldırmak için J2EE standartları ortaya çıkmış. Şirket olarak bu standartın üzerine çıkabilirsiniz ama en azından bunları sağlamakla yükümlüsünüzdür.


Diyelim ki müşteriden istek geldi ve bize maç sonucunu sordu. Ama sen, application server olarak, bunu senin yerine başka biri yapsın istiyorsun. Tam tabiriyle herkese "iş çakmak" esastır. :) Veritabanına gitmesi için JDBC kullanıyorsun. Bu görevlendirme, az önce bahsettiğim, J2EE standardıdır. Yoksa bu işi kendin de yapabilirsin. JDBC'ye, Beşiktaş - Sarıyer maçının skorunu getir diyorsun. O da getiriyor. Sen de bunu göstermek için bir sayfa ayarlıyorsun ve skoru gösteriyorsun.
Ama sayfayı neden sen yapıyorsun? Onu da başkasına itelemek lazım. :) Bu iş için de, yine J2EE  standatı gereği, JSP'yi görevlendiriyorsun. JSP'ye, JDBC'nin getirdiği bilgiyi alıp sayfalamasını söylüyorsun.
Peki ama bunların bilgiyi getirtmesiyle neden uğraşıyorsun? Bir istek geldiğinde, birine o isteği ver. Kim ne yapar, nasıl yapar ilgilenme. İşte EJB de tam da bunun için var.
Ancak bunların nerede olduğunu, adresini bilmen lazım ki JNDI da bu iş için emrinize amade. :)

Yani en baştan kısaca toparlamak gerekirse.. :) İstek size geldi. Bu işi yapacak EJB'nin adını biliyorsunuz, tanıyorsun ama adresini bilmiyorsunuz. JNDI'dan adresini alıyorsunuz(JNDI'ı katalog gibi düşünebilirsiniz). İşi EJB'ye verdik. O da ilgili JDBC adresi için, JNDI'ın kapısını çalar ve o da JDBC'ye işi verir.

Buraya kadar tamam isek, şu soruyu soralım: istek direkt gelebiliyor mu? Tabi ki hayır. JAAS isimli bir diğer bileşen de güvenlik işlerini yürütmekte. İstek authenticator'a gidiyor. Authenticator da token var mı diye elinde bakar. Yoksa login gibi bir güvenlik işlemine yönlendiriyor. Login olunca, isteğin artık bir token'ı oluyor. Authenticator'a tekrar gidiyor ve bu kez içeri giriyor ve isteği size iletebiliyor.

Daha çok kavram var ama kısaca mimarisinden de bahsedeyim. Clientı en üstte düşünecek olur isek, arada DMZ bölgesi vardır(kimseye ait olmayan bölgedir bu; production ortamında clienttan korumak içindir). Araya web server da konabilir. Bu ilk kısma web katmanı denmekte. Akabinde, application server'ların bulunduğu App Server katmanı var. En altta da backend katmanı(db'nin olduğu) bulunmakta. Yani güvenlik amacıyla 3 katmanlı bir mimari tasarlanmış oldu. Application server birden fazla olabilir. Ama bunun için web server'ın sayısını da arttırmanız lazım. Tabi web server sayısı artınca, client'ın nereye gideceğini bilebilmesi için Load Balancer'ı da client'ın peşine yerleştirmeniz gerekir. :) Bunlar uzar gider. :)

Domain, proxy gibi kavramlar da var ama onlara belki diğer yazımda girerim, şimdilik bu yeterli.

Görüşürüz birazdan.