SAP Business One SQL mı HANA mı? İki Veritabanı Seçeneği Arasındaki Farklar

SQL ve HANA seçimi neyi değiştirir?

SAP Business One, uygulama katmanı bakımından aynı üründür; ancak altındaki veritabanı platformu iki farklı seçenekle kurulabilir: Microsoft SQL Server tabanlı sürüm ve SAP HANA tabanlı sürüm. Modüller, iş mantığı ve gündelik ekranlar büyük ölçüde tanıdık kalır; değişen şey verinin nerede ve nasıl işlendiğidir.

Seçim ERP'yi değil, aynı ERP'nin çalışacağı veri altyapısını belirler. Etkisi de tek bir başlıkla sınırlı kalmaz: performans algısı, raporlama ve analitik olanakları, sunucu ve işletim sistemi tercihi, sistem yönetimi rutini, yedekleme kurgusu ve toplam sahip olma maliyeti aynı anda değişir.

Yönetim açısından belirleyici olan, tek bir ekranın hızından çok veriye ne kadar hızlı ve ne kadar derin soru sorulabileceği ile bu altyapıyı kimin hangi eforla ayakta tutacağıdır.

Temel mimari fark: disk tabanlı ilişkisel yaklaşım ve in-memory sütun yönelimli yaklaşım

Microsoft SQL Server, klasik ilişkisel veritabanı yaklaşımını temsil eder: veri esas olarak diskte tutulur, sık kullanılan bölümler bellekte önbelleklenir ve sorgular indeksler üzerinden çalışır. Bu mimari onlarca yıldır kurumsal uygulamaların altında çalışmakta olan, olgun ve yaygın bilinen bir yapıdır.

SAP HANA ise in-memory (bellek içi) ve büyük ölçüde sütun yönelimli (column store) bir yaklaşım kullanır: veri, çalışma sırasında ana bellekte tutulacak biçimde tasarlanır ve sütun bazlı saklama ile sıkıştırma birlikte kurgulanır. Kalıcılık yine disktedir; fark, sorguların çalışma anında veriye erişme biçimidir.

SQL Server tarafında hız, doğru indeksleme ve iyi tasarlanmış sorgularla yönetilen bir mühendislik konusudur. HANA tarafında ise özellikle geniş veri kümesi üzerinde toplulaştırma yapan sorgular için mimari, tasarımı gereği avantajlı olabilir. "Olabilir" kelimesi burada önemlidir; kazanım veri hacmine, sorgu tipine ve donanım kurgusuna göre değişir.

Veri saklama ve işleme yaklaşımı

Satır yönelimli saklamada bir kaydın bütün alanları yan yana durur; "şu faturayı getir" gibi tek kayda dokunan işlemler için bu doğal ve verimlidir. Sütun yönelimli saklamada ise aynı alanın bütün değerleri bir arada durur; "son on iki ayın satış tutarını müşteri kırılımında topla" gibi az sayıda sütunu çok sayıda satır boyunca okuyan işlemler için bu yerleşim uygundur.

Sütun yönelimli yapı, aynı sütundaki değerlerin benzerliği sayesinde sıkıştırmaya da daha yatkındır. Bu, belleğe daha fazla verinin sığdırılabilmesi anlamına gelir; ancak sıkıştırma oranı veri yapısına göre değişir ve genel geçer bir katsayı ile ifade edilemez.

Pratikte iki tarafta da ERP yükü karmadır: gün içinde çok sayıda küçük işlem (fatura, irsaliye, stok hareketi) ve bunların üzerine binen rapor sorguları. Bu nedenle "hangi mimari daha iyi" sorusu, ancak sizin işlem/rapor karışımınız üzerinden anlamlı biçimde cevaplanır.

Performansı doğru değerlendirmenin yolu

Performans, iki platformun karşılaştırıldığı en tartışmalı başlıktır; çünkü sonuç tek bir teknolojiye değil, veri hacmine, veri modelinin kalitesine, sorgu tasarımına, donanıma ve eşzamanlı kullanıcı davranışına bağlıdır. Bu yüzden pazarlama malzemelerindeki genel hız iddialarını değil, kendi verinizle yapılan ölçümü esas alın.

Sağlıklı bir değerlendirme, gerçek veri kopyanız üzerinde ve gerçek senaryolarla yapılır. Kritik olan tekil sorgu süresi değil, iş gününüzün en yoğun anındaki toplam davranıştır: ay sonu kapanışı, sezon içi sipariş yoğunluğu veya bütün yöneticilerin aynı sabah aynı raporu açtığı an.

Ölçümde şu işlem gruplarını ayrı ayrı gözlemleyin; her biri farklı bir mimari özelliği zorlar:

• Tekil işlem yanıt süreleri: belge açma, kaydetme, stok/fiyat sorgulama gibi gündelik ekran işlemleri.
• Toplu işlemler: fiyat güncelleme, toplu belge oluşturma, dönemsel kapanış işlemleri, veri aktarım koşuları.
• Geniş kapsamlı rapor sorguları: uzun tarih aralığı, çok kırılımlı toplulaştırma ve stok/maliyet analizleri.
• Eşzamanlılık: birden fazla kullanıcı aynı anda ağır rapor çalıştırırken işlem ekranlarının davranışı.
• Planlama koşuları: üretim ve malzeme ihtiyaç planlaması gibi hesaplama yoğun süreçlerin toplam süresi.
• Entegrasyon yükü: dış sistemlerden gelen otomatik kayıt akışının yoğun saatlerdeki etkisi.

Analitik beklentisi: veriye ne kadar derin soru soruyorsunuz?

İki platform arasındaki farkın en görünür olduğu alan analitiktir. Eğer işletmenizde veri esas olarak kayıt tutmak ve standart dönemsel raporları almak için kullanılıyorsa, analitik beklentisi düşüktür ve bu başlık kararınızda belirleyici olmayabilir.

Buna karşılık yöneticiler gün içinde sık sık kırılım değiştirerek soru soruyorsa ("bu marjı müşteri bazında göster, sonra ürün grubuna indir, sonra son üç ayla karşılaştır"), analitik yük ciddi biçimde artar. In-memory ve sütun yönelimli mimari, bu tür geniş toplulaştırma sorgularında avantaj sağlayabilir; ancak kazanımın büyüklüğü veri hacmine ve sorgunun yapısına göre değişir.

Kararı verirken bugünkü kullanım kadar yakın gelecekteki beklentiyi de yazın: yeni açılacak lokasyonlar, artan sipariş adedi, e-ticaret kaynaklı işlem sayısı ve yönetimin talep ettiği yeni gösterge tabloları, analitik yükü kısa sürede değiştirebilir.

Raporlama araçları iki tarafta nasıl değişir?

SAP Business One her iki platformda da kapsamlı bir raporlama zemini sunar: standart raporlar, sorgu tabanlı özel raporlar, Crystal Reports ile hazırlanan biçimli çıktılar ve yönetim panelleri her iki tarafta da kullanılabilir. Yani "SQL tarafında rapor alınamaz" gibi bir durum yoktur.

Fark, ileri analitik ve gömülü veri keşfi araçlarında ortaya çıkar. HANA tabanlı sürüm, sürüm ve yapılandırmaya bağlı olarak ek analitik yetenekler ve veri modelleme olanakları sunabilir; SQL tabanlı kurulumlarda benzer ihtiyaçlar çoğunlukla iyi tasarlanmış sorgular, raporlama katmanı veya dış iş zekâsı araçlarıyla karşılanır.

Bakılması gereken şey, yönetimin gerçekten kullandığı rapor listesidir: bu liste hangi platformda daha az özel geliştirmeyle karşılanıyor? Kimsenin açmadığı bir gösterge tablosu, hangi mimaride üretilirse üretilsin işe yaramaz. Mevcut rapor envanterinizi çıkarmak, bu başlıktaki en kısa yoldur.

Altyapı gereksinimleri ve işletim sistemi

Bu başlık, teknik ekip için kararın en somut ayağıdır. Microsoft SQL Server tabanlı SAP Business One, Windows Server ekosisteminde çalışır. Sunucu, yedekleme ve yetkilendirme düzenini bu ekosistem üzerinde kurmuş işletmelerde mevcut yapı doğrudan kullanılabilir.

SAP HANA tabanlı sürüm ise Linux tabanlı sunucu işletim sistemleri üzerinde çalışır ve kendi kurulum, sürüm ve destek gereksinimleriyle gelir. Desteklenen tam sürüm ve platform bileşimlerini genel yorumlardan değil, SAP'nin güncel ürün dokümantasyonundan ve iş ortağınızın teyidinden alın; bu liste zamanla güncellenir.

İşletme açısından anlamı şudur: HANA tercihi yalnız bir veritabanı seçimi değil, aynı zamanda bir işletim sistemi ve operasyon modeli seçimidir. Bu, ek yetkinlik veya dış hizmet ihtiyacı doğurabilir; kararı verirken bunu bir sürpriz değil, planlanmış bir kalem olarak ele alın.

Donanım yaklaşımı ve boyutlandırma

İki platformun donanım felsefesi farklıdır. Disk tabanlı yaklaşımda dengeli bir işlemci, bellek ve hızlı depolama üçlüsü aranır; bellek önemlidir ama tüm veri kümesini karşılamak zorunda değildir. In-memory yaklaşımda ise bellek, tasarımın merkezindedir ve boyutlandırma esas olarak veri hacmi ile büyüme beklentisine göre yapılır.

Bu rehberde bilinçli olarak bellek, disk veya çekirdek rakamı verilmiyor; çünkü doğru boyutlandırma sizin veri hacminiz, kullanıcı sayınız, işlem yoğunluğunuz ve büyüme planınıza göre hesaplanır. Sağlıklı yol, iş ortağınızın güncel boyutlandırma yönergeleriyle sizin gerçek verinize bakarak hesap yapmasıdır.

Boyutlandırmada üç şeyi ayrı ayrı sorun: bugünün ihtiyacı, beklenen veri ve işlem büyümesi, test/geliştirme ortamının gereksinimi. Yalnız bugünkü ihtiyacı karşılayan bir boyutlandırma, kullanım büyüdükçe ek altyapı ihtiyacı doğurabilir.

Mevcut BT ekibinizin yetkinliği

Bir platformu kimin yöneteceği, kararın ayrılmaz parçasıdır. Windows Server ve SQL Server altyapısı kullanan işletmelerde mevcut sistem yönetimi deneyimi seçim üzerinde etkili olabilir; SQL tabanlı kurulum, ekibin bilinen araçlarla devam etmesini sağlar.

HANA tabanlı kurulumda Linux yönetimi, HANA'ya özgü yönetim araçları ve farklı bir izleme rutini devreye girer. Bu aşılamaz bir engel değildir; ancak ya ekibin eğitilmesi ya da yönetimin bir iş ortağına devredilmesi gerekir. Kararın gerçek maliyeti, bu tercihin de içine yazılmasıyla ortaya çıkar.

Yönetici için pratik test şudur: sistem gece bir sorun çıkarırsa, sabah kim müdahale edecek ve bu kişi o platformu gerçekten biliyor mu? Cevap net değilse, tercih edilen platform ne olursa olsun bir destek sözleşmesi kararın parçası olmalıdır.

Sistem yönetimi, bakım ve yedekleme

Gündelik operasyon, karşılaştırmanın en az konuşulan ama en uzun ömürlü başlığıdır. Her iki platformda da düzenli yedekleme, yedekten dönüş tatbikatı, güncelleme/yama yönetimi, performans izleme, disk ve kaynak takibi ile yetkilendirme yönetimi zorunludur.

Fark, bu işlerin hangi araçlarla ve hangi rutinle yapıldığındadır. SQL Server tarafında bakım planları, yedekleme ve izleme araçları geniş bir yönetici kitlesince bilinir. HANA tarafında ise platforma özgü yönetim ve izleme araçları ile Linux üzerindeki işletim rutini öğrenilmelidir.

Yedekleme başlığında ortak kural değişmez: yedeğin varlığı değil, geri dönebildiğiniz yedek anlamlıdır. Hangi platformu seçerseniz seçin, geri yükleme tatbikatını takvime bağlayın ve kurtarma süresi beklentinizi (sistem ne kadar sürede ayağa kalkmalı) yazılı olarak belirleyin.

Entegrasyon ve özel geliştirme açısından fark

Entegrasyonların büyük bölümü SAP Business One'ın uygulama katmanındaki programlama arayüzleri üzerinden kurulur; bu nedenle iş mantığı düzeyinde tasarım her iki platformda da benzer ilerler. Ancak kullanılabilir arayüzlerin kapsamı, tercih edilen yöntemler ve bazı eklentilerin platform desteği sürümlere göre farklılık gösterebilir.

Doğrudan veritabanına yazılmış sorgular içeren özel raporlar ve geliştirmeler, platform değişiminden en çok etkilenen unsurlardır: SQL dilinin platforma özgü söz dizimi farkları nedeniyle bu sorguların gözden geçirilmesi ve uyarlanması gerekebilir. Standart arayüzler üzerinden yazılmış geliştirmeler ise genellikle daha az etkilenir.

Pratik öneri: karar öncesinde envanter çıkarın. Kaç özel rapor, kaç sorgu, kaç eklenti ve kaç entegrasyon çalışıyor; bunların hangileri doğrudan veritabanına bağımlı? Bu liste, geçiş eforunun en gerçekçi göstergesidir ve üçüncü taraf eklentiler için tedarikçi teyidi alınmasını da kolaylaştırır.

Mevcut sistemden geçiş ve migration değerlendirmesi

SQL tabanlı bir SAP Business One kurulumundan HANA tabanlı sürüme geçmek mümkündür; bunun için tanımlı bir geçiş süreci ve araçları vardır. Ancak bu, bir düğmeye basmak değil, planlanan bir projedir: ortam hazırlığı, veri taşıma, özel nesnelerin uyarlanması, test ve geçiş penceresi içerir.

Geçiş projesinin eforunu belirleyen ana etkenler; veri hacmi, özel geliştirme ve rapor sayısı, kullanılan eklentiler, entegrasyon adedi ve kabul testi kapsamıdır. Sade bir kurulumda çalışma görece dar tutulabilirken, yıllar içinde çok sayıda özel nesne biriktirmiş bir sistemde kapsam belirgin biçimde büyür.

Bu nedenle geçiş fikri gündeme geldiğinde ilk adım tarih belirlemek değil, bir hazırlık analizi yapmaktır: neyin taşınacağı, neyin sadeleştirileceği ve neyin bu vesileyle emekliye ayrılacağı netleşmelidir. Çoğu projede en büyük kazanım, taşınmayacak eski nesnelerin ayıklanmasıyla elde edilir.

Lisanslama ve ticari çerçeve nasıl değerlendirilir?

Bu rehber bilinçli olarak fiyat rakamı içermez. Doğru yaklaşım, iki seçeneği aynı kalem listesi üzerinden karşılaştırmaktır: uygulama lisansları, veritabanı tarafındaki lisans veya kullanım hakkı, yıllık bakım/abonelik, sunucu ve işletim sistemi maliyeti ile bunları işletecek insan kaynağı.

Yapısal fark şudur: Microsoft SQL Server tarafında veritabanı lisansı ayrı bir kalem olarak ele alınırken, HANA tarafında veritabanı SAP tarafındaki ticari çerçevenin içinde konumlanır. Her iki senaryoda da geçerli koşullar, kullanıcı sayısı ve edinim modeli SAP'nin güncel fiyat listesi ve iş ortağı teklifiyle netleşir.

Teklif alırken iki seçeneği kalem kalem yan yana koyduğunuz tek bir tablo isteyin. Farklı formatlarda gelen iki teklif karşılaştırılabilir değildir; aynı kalem başlıklarıyla hazırlanan iki teklif ise kararı birkaç dakikada görünür kılar.

Toplam sahip olma maliyeti (TCO) penceresinden bakmak

Sağlıklı karşılaştırma ilk fatura ile değil, 3-5 yıllık toplam sahip olma maliyeti ile yapılır. Bu pencereye lisans ve bakım kadar sunucu yenileme, işletim sistemi ve platform güncellemeleri, yedekleme altyapısı, izleme, destek hizmeti ve gerekli eğitimler de girer.

Aynı pencerenin diğer tarafında fayda vardır: raporun ne kadar hızlı hazır olduğu, kapanışın kaç gün sürdüğü, yöneticinin karar için beklediği sürenin kısalması ve BT ekibinin bakıma ayırdığı zamanın azalması. Yalnız gider tarafını yazan bir karşılaştırma eksiktir; yalnız fayda tarafını yazan ise gerçekçi değildir.

Bu hesabı kendi rakamlarınızla yapın. Genel geçer yüzdeler yerine, kendi kapanış sürenizi, kendi rapor bekleme sürenizi ve kendi BT eforunuzu ölçün; iki senaryoyu bu ölçümler üzerinden konuşun.

Hangi işletme hangi seçeneği değerlendirebilir?

Genel bir kural yerine profil bazlı bir çerçeve daha yararlıdır. Microsoft SQL Server tabanlı sürüm; standart ERP süreçlerini yürüten, analitik beklentisi ölçülü, mevcut BT ekibi Windows ekosisteminde güçlü ve başlangıç yatırımını dengeli tutmak isteyen işletmeler için değerlendirilebilir bir seçenektir.

SAP HANA tabanlı sürüm; veri hacmi hızla büyüyen, yöneticilerin gün içinde sık sık kırılım değiştirerek analiz yaptığı, gömülü analitik yeteneklerinden yararlanmayı planlayan ve Linux tabanlı altyapıyı kendi ekibiyle veya bir iş ortağıyla sürdürebilecek işletmeler için değerlendirilebilir.

İki profil arasındaki gri alan geniştir; bu yüzden kararı sezgiyle değil, aşağıdaki maddeleri netleştirerek verin. Bu liste aynı zamanda iş ortağınızdan teklif isterken kullanabileceğiniz hazır bir gündemdir:

• Veri hacmi ve büyüme: bugünkü yıllık işlem adediniz nedir, üç yıl sonra hangi seviyeyi bekliyorsunuz?
• Kullanıcı profili: kaç kişi işlem giriyor, kaç kişi rapor ve analiz tüketiyor?
• Rapor envanteri: yönetimin düzenli kullandığı raporlar hangileri ve bunların kaçı özel geliştirme?
• Analitik beklentisi: raporlar sabit mi, yoksa kullanıcı kırılımı değiştirerek mi analiz yapıyor?
• Özel nesneler: kaç özel sorgu, kaç eklenti ve kaç entegrasyon çalışıyor; hangileri doğrudan veritabanına bağımlı?
• BT yetkinliği: Linux ve platforma özgü yönetim işlerini kim üstlenecek; iç ekip mi, iş ortağı mı?
• Süreklilik beklentisi: kabul edilebilir kesinti süresi nedir, yedekten dönüş ne kadar sürmeli?
• Altyapı tercihi: kendi sunucunuz mu, barındırma mı, bulut mu; hangi model kaynaklarınıza uyuyor?
• Bütçe yapısı: başlangıç yatırımı mı, dönemsel gider mi tercih ediliyor?
• Ölçüm planı: kendi veri kopyanızla hangi senaryoları test edeceksiniz ve başarı kriteri ne olacak?

Sık Sorulan Sorular