Veritabanı nedir: aynı sistemde neden iki tür veri deposu durur

Veritabanı, bir yazılımın kayıtlarını sonradan bulunabilir ve birbirine bağlanabilir biçimde tuttuğu katmandır. Hangi veri deposunun kullanılacağı bir ürün tercihi olarak değil, kaydın şeklinin tanımlandığı yerde kararlaşıyor: alanlar baştan mı belli, kayıt başına mı değişiyor. Vipkurum platformu kayıtlarını iki depo ailesinde birlikte tutuyor: optik okuma sonucu sınavın kendi kaydına yazılıyor, kırpılan soru kayıtları doküman tarafında duruyor.

Depo kaydı alanlara bölerek saklar, program kapandıktan sonra yerinde tutar ve bir kaydın başka bir kaydı işaret etmesine izin verir. Teklifinizde ilişkisel veritabanı ya da doküman veritabanı ifadesi geçiyorsa o satır yazılımın kalitesi hakkında bir şey söylemiyor; kayıtlarınızın hangi şekilde duracağını söylüyor. Aynı teklifte ikisinin birden geçmesi de fazlalık işareti değil: kayıtlarınızın hepsi aynı şekilde olmadığında kayıt katmanında iki aile yan yana durabiliyor.

Veritabanı nedir, bir işletmenin kaydıyla ne yapar

Tanımı en küçük biriminden kurmak gerekiyor. Bir veri deposunun tuttuğu şey dosya değil, kayıt. Kayıt da alanlardan oluşuyor ve her alan tek bir şey hakkında tek bir bilgi taşıyor: bir randevu kaydının saati, bir hasta kaydının adı, bir sınav kaydının puanı. Alanların toplamı o kaydın şeklini veriyor. Bu yazıda geçen şekil kelimesi her yerde bunu gösteriyor: kaydın hangi alanları taşıdığını.

Depo bu kayıt için şunları birden üstleniyor. Kayıt, onu yazan program kapandıktan sonra da yerinde duruyor; kalıcılık buradan geliyor. Deponun tamamı okunmadan bulunabiliyor, yani adıyla, tarihiyle ya da bağlı olduğu başka bir kayıtla aranabiliyor. Ve başka bir kaydı işaret edebiliyor: randevu kaydı hangi hastaya ait olduğunu kendi üstünde taşıyor.

Bu işlerin hiçbirini klasörde duran bir dosya yapmıyor. Dosyayı açtığınızda içindekini görürsünüz, ama dosyanın hangi müşteriye ait olduğunu, hangi işin parçası olduğunu ve hangi tarihte hangi tutara bağlandığını yazılım bilmez. Bilmesi için bu bilgilerin alan olarak tanımlanmış olması gerekiyor. Tanımlı değilse bilgi sistemde değil, dosyanın adında ya da onu kaydeden kişinin aklında yaşıyor.

İşletme açısından sınır tam buradan geçiyor. Sisteminizin size işiniz hakkında söyleyebileceği şey, deponun kayıt olarak ne tuttuğu kadardır. Ay sonunda bir soruya cevap alamıyorsanız sebep çoğu zaman rapor ekranı değil, o cevabı üretecek alanın hiçbir kayıtta tanımlı olmaması. Rapor ekranı değişebilir; tanımlı olmayan alan geçmişe dönük doldurulamıyor. Yeni bir alan bugün açılsa bile, geçen yılın kayıtlarında o alan boş kalıyor.

Hesap tablosu, dosya deposu ve önbellek neyi yapmaz

Veri tutan her şey veritabanı değil. Elinizde çoğu zaman bir hesap tablosu var ve orada da satırlar, sütunlar, hatta formüller duruyor. Ayrım şurada: hesap tablosu satır tutuyor ama satırlar arasında yazılımın takip edebileceği bir bağ tutmuyor. O bağ tabloya bakan kişinin hafızasında yaşıyor. Bu satırın müşterisi şu sekmedeki filanca satır bilgisi tabloda yazılı değil; onu bilen kişi işten ayrıldığında bağ da gidiyor. Formül bir bağ gibi görünüyor ama hücre adresine bağlanıyor, kayda bağlanmıyor.

Dosya deposu başka bir iş yapıyor. Dosyayı olduğu gibi tutuyor ve geri veriyor. Dosyanın hangi kayda ait olduğu ayrı bir bilgi ve ayrı bir yerde yaşıyor. Şu an inşa ettiğimiz Secretum’da bu ayrım açıkça görünüyor: karakterin kendi kaydı doküman olarak duruyor, karakterin ürettiği görsel ise dosya olarak ayrı bir yere yazılıyor. Genel kural şu: dosyanın hangi kayda ait olduğu kayıtta tutulur. Dosya deposunu tek başına kullanmak, bu bilgiyi dosya adına sıkıştırmak demek olurdu.

Önbellek ise ayrı bir aile sayılmıyor. Önbellekteki okuma deponun kendisinden türetiliyor; kaybolan bir kaydı geri getirecek kopyanın yerine geçmiyor. Bu sınırı veri yedekleme ve geri yükleme planı üzerine yazdığımız yazıda ayrıca açtık, o yüzden burada tek cümlede bırakıyoruz. Önbelleği depo saymak, aynanın karşısındakini başka bir nesne saymaya benziyor.

Ayrımın bir karşı tarafı da var ve açıkça yazmak gerekiyor: hesap tablosu her zaman yanlış araç değil. Tek kişinin tuttuğu, satırları birbirine bağlanmayan bir liste için veri deposu kurmak bir kazanç getirmiyor. Ayrımı gerektiren şey satır sayısı değil, satırların birbirine bağlanma ihtiyacı. Yapılan iş bir yerde, kesilen fatura başka bir defterde duruyorsa ve ay sonunda bunları birleştiren şey birinin elle yaptığı karşılaştırmaysa sınır çoktan geçilmiş oluyor. O karşılaştırma aslında eksik bir bağın yerine geçiyor.

İki depo ailesi: tablo satırı ve kendi başına duran belge

Teklifte gördüğünüz iki terim, kaydın nasıl kurulduğunu anlatan iki ayrı biçimin adı. Terimler ürün adı değil, kuruluş biçiminin adı.

İlişkisel tarafta kayıt bir tablonun satırıdır. Hangi alanların bulunacağı baştan tanımlıdır ve o tablodaki her satır aynı alanları taşır. Hasta tablosundaki her hasta kaydında ad, doğum tarihi ve iletişim alanı vardır; biri boş kalabilir ama alan yine de tanımlıdır. Tanımın bir yan ürünü var: aynı tablodaki kayıtlar tek bir sorguyla toplanabiliyor, çünkü hepsinin aynı alanları taşıdığı biliniyor.

Kayıtları birbirine bağlayan şey bir alanın başka bir kaydı işaret etmesi. Randevu kaydındaki bir alan hangi hastaya ait olduğunu söyler; başka bir alan hangi tedavi adımına bağlı olduğunu söyler. İlişkisel modelde kayıtlar tablolarda durur ve bir kaydı ötekine bağlayan şey, başka bir kaydı işaret eden alandır. Terim bir hızı, bir kaliteyi ya da bir güvenlik seviyesini anlatmıyor; bu yüzden onu bir övgü olarak okumak yanlış olur.

Alanların baştan tanımlı olmasına şema deniyor. Şema, deponun kaydın şekli hakkında bildiği şey: hangi alanlar var, hangileri zorunlu, hangi alan hangi başka kaydı işaret ediyor. Şema tanımlıysa kontrolü deponun kendisi yapabiliyor; tanımsız bir alana yazmaya çalışan kod orada duruyor. Bu, kaydın bütünlüğünü uygulama katmanının dışında bir yere koymak demek.

Doküman tarafında kayıt kendi şeklini üstünde taşıyor. Aynı depodaki kayıtlar farklı alanlar taşıyabiliyor ve yeni bir alan geldiğinde şema baştan tanımlanmıyor. Kayıt, içinde ne varsa onunla birlikte okunuyor; şekli kaydın kendisinden öğreniliyor. Bunun sonucu şu: kaydın bütünlüğünü garanti eden yer artık depo değil, kaydı yazan kod.

Buradan çıkan sonuç bir sıralama değil. Aileler birbirinin yerine geçen rakip ürünler değil; farklı kayıt şekilleri için farklı kuruluş biçimleri. Hangisinin daha uygun olduğu sorusu, kaydın şeklini sormadan cevaplanamıyor. Soruyu tersten kurmak gerekiyor: elinizde ne tür bir kayıt var.

Aynı sistemde iki depo türü neden yan yana durur

Soru şu hâle geliyor: bir sistem neden ikisini birden taşır.

Vipkurum platformu kayıtlarını iki depo ailesinde birlikte tutuyor. Ders programı, sınav, öğrenci, veli ve ödeme işleyişi tek uygulamada duruyor, ama kayıt katmanında MySQL ve MongoDB yan yana çalışıyor. Aynı kurulumun tek kayıt katmanıyla çok yüzeye hizmet etme yüzünü ve kurum sınırının nereden çizildiğini çok kiracılı sistemlerin nasıl kurulduğu yazısında anlattık. Buradaki soru farklı: hangi kayıt hangi aileye düşüyor.

Dağılım en net aynı çatı altında geliştirilen araçlarda görünüyor. Optik okuma aracı form görüntüsünden işaretlemeleri çıkarıyor ve çıkardığı sonucu sınavın kendi kaydına yazıyor. Sonuç tablo tarafında, mevcut bir kaydın üstüne düşüyor. Okuma zincirinin kendisini, tarayıcıdan kayda kadar, optik okuyucu donanımı olmadan sınav değerlendirme yazısında açtık; burada bizi ilgilendiren tek şey sonucun hangi aileye düştüğü.

Soru kırpma aracında kayıtlar öteki aileye düşüyor. Kırpılan görseller ve soru kayıtları doküman tarafında duruyor. Araçlar aynı platformun çatısı altında geliştirildi ve kayıtları aynı aileye düşmedi. Her olgu tek tek bakıldığında bir şey söylemiyor; yan yana konduğunda, iki aracın da görüntü işlediği ama kayıtlarının aynı aileye düşmediği görünüyor; dağılım araçla değil kayıtla ilgili.

Buradan bir tercih hikâyesi çıkarmıyoruz. Elimizde yazılı olan şey dağılımın kendisi: hangi kaydın nerede durduğu. Her aracın neden o tarafta durduğuna dair bir gerekçe kaydımız yok ve olmayan bir gerekçeyi yazmıyoruz. Gözlenebilir olan şu: araçların kayıt olarak tuttuğu şeyin şekli farklı. Sınav sonucu her formdan aynı biçimde çıkıyor ve mevcut bir kayda bağlanıyor. Kırpılan soruda ise cevap, sorunun kendi kaydının içinde duruyor.

Bir yanlış okumayı baştan kapatmak gerekiyor. Her araç iki depoyu birden kullanıyor değil. Optik okuma aracının yığınında doküman tarafı hiç yok; soru kırpma aracının yığınında tablo tarafı yok. İki aile platformun bütününde yan yana duruyor, her aracın içinde değil. Bu ayrım yazılmazsa cümle şöyle anlaşılıyor: her sistem iki depo kurar. Kurmuyor.

Buradan akla gelen soru bakım: ailelerin ikisini birden taşımak bakım yükünü artırır mı? Portföyümüzde iki ailenin bir arada durduğu bir kurulum var, ama bakım bedelini rakamla söyleyemeyiz.

Ölçeğin bir sınırı var ve burada söylemek doğru olur. Birden fazla kurumun aynı sistemi kendi adıyla paylaştığı kurulumun kendi kararları var; o kararlar bu yazının konusu değil, kurumsal yazılım tarafında ayrı bir işin konusu.

Kaydın şekli hangi depoya düştüğünü belirler

Dört gerçek kaydı yan yana koyunca ortaya çıkan düzen şu: alanları baştan belli olan ve birbirine bağlanan kayıtlar tablo tarafında duruyor, şekli kayıttan kayda değişen kayıtlar doküman tarafında. Satırlara bunu arayarak girin.

Klinik satırının olgusu şu. Diş kliniği CRM’inde plan diş bazında kurulup sıralı seanslara bölünüyor; hangi işlemin hangi dişe gittiği planın üstünde duruyor. Randevu da o planın tek bir adımına tutturuluyor. Bağ ekranda değil kayıtta duruyor. Bu bağın neden böyle kurulduğu ayrı bir soru ve onu randevu ile servis talebinin ayrılması üzerine yazdığımız yazıda açtık; burada bizi ilgilendiren tek şey, kaydın alanlarının baştan belli olması. Hangi diş, hangi işlem, kaçıncı seans: hepsi de her plan kaydında aynı yerde.

Kırpılan soru satırı karşı ucu gösteriyor. Kırpılan soru görseliyle ve cevabıyla tek parça olarak duruyor; cevap ayrı bir belgede değil, sorunun kendi kaydının içinde. Kaydın kendi içinde bütün olması, doküman şeklinin tanımına uyan en açık örnek. Aynı kaydı tablo tarafında kurmak isteseydiniz soru, görsel ve cevap ayrı satırlar hâline gelirdi ve aralarındaki bağ ayrıca tanımlanırdı.

Tablo bir yasa yazmıyor. Dört kaydın okunmasından çıkan bir gözlem bu. Portföyümüzde bu dördün dışında yan yana koyabileceğimiz bir eşleştirme yok ve olmayan bir örnek icat etmiyoruz. Şu şekildeki kayıt şu depoya gider cümlesi yazılabilseydi karar da kolay olurdu. Olmuyor, çünkü aynı şekil farklı sistemlerde farklı bağlarla duruyor; bağ değiştiğinde kaydın gideceği yer de değişiyor.

Şekli hâlâ büyüyen bir kayıtla ne yapıyoruz

Secretum’u şu an inşa ediyoruz; ürün henüz yayında değil ve karakter kaydının kuruluşu üzerinde çalışmayı sürdürüyoruz. Portföyümüzde doküman tarafının gerekçesinin yazılı olduğu tek yer burası, o yüzden bu bölüm tek bir kaydı anlatıyor.

Karakter kaydını doküman olarak tutuyoruz. Sebep kaydın hâli: karakter yeni bir özellik aldığında kaydın taşıdığı alan listesi uzuyor ve bu uzama henüz durmuş değil. Her eklemede kaydın şeklini baştan tanımlamak zorunda kalmıyoruz; yeni alan kaydın içinde doğuyor. Alan listesi bugün kapatılsaydı, yarın gelen her özellik önce kaydın şeklini açmayı gerektirirdi.

Kalıcılık tarafı da burada görünüyor. Karakter bir hesabın altında kalıcı kayıt olarak duruyor; oturum kapandığında adı, ayarları ve o güne kadar biriken geçmişi yerinde kalıyor. Kaydın oturuma değil hesaba bağlanması, kaydın şeklinden ayrı bir karar: biri kaydın neye benzediğini belirliyor, öteki neye bağlı olduğunu.

Esnekliğin bedelini de yazmak gerekiyor. Kaydın şekli her kayıtta aynı olmadığında, bir alanın hangi kayıtlarda bulunduğunu deponun kendisi garanti etmiyor. O garanti kodda kurulmak zorunda kalıyor. Tablo tarafında şemaya düşen iş, doküman tarafında uygulama katmanına geçiyor. Bu bir takas: şemanın sağladığı kontrolü bırakıp, kaydın şeklini değiştirme serbestliğini alıyorsunuz.

Karşı durum da net. Şekli oturmuş bir kayıtta aynı esneklik bir kazanç değil. Klinikteki plan kaydının alanları baştan belli ve orada kayıt tablo tarafında duruyor; esnekliğe ihtiyacı yok, çünkü hangi alanların geleceği sorusu çoktan kapanmış. Esnekliği gerektiren şey ürünün yeni olması da değil. Yeni bir üründe de kayıt şekli oturmuş olabilir. Gerekçe tek bir yerde duruyor: kaydın hangi alanları taşıyacağı henüz yazılmamışsa, şekli kilitlemek erken olur.

Teklifte depo türü yazıyorsa kaydınız hakkında ne söyler

Başa dönelim. Teklifte geçen depo türü yazılımın kalitesini adlandırmıyor; kayıtlarınızın şeklini adlandırıyor. Okuduğunuz satır size şunu soruyor: alanları baştan belli olan ve birbirine bağlanan kayıtlarla mı çalışıyorsunuz, yoksa şekli büyümeye devam eden kayıtlarla mı.

Depo türü işletmenin sorduğu soruyu tek başına cevaplamıyor. Vipkurum’da kayıt katmanında iki aile birden var, ama kurumun sınırı depo ailesinde değil kaydın kendisinde duruyor: bir kurumun öğrenci, veli ve ödeme kayıtları diğerine görünmüyor ve yönetici raporunu yalnız kendi kurumunun verisinden alıyor. Sınırı taşıyan şey kaydın hangi depoda durduğu değil, neye bağlandığı. Aynı kayıt öteki ailede tutulsaydı sınır sorusu yine aynı yerde sorulurdu.

Aynı ayrım klinik tarafında da görünüyor. Diş kliniğinde plan, randevu ve fatura aynı hasta kaydından okunuyor. Bu bir depo türü kararı değil, kaydın neye bağlandığı kararı. Depo türünü değiştirmek bu bağı kurmuyor; bağı kuran şey kaydın tanımı. İşletme olarak teklifte okuduğunuz satırın size söylediği şey de bu ikinci karar hakkında değil, birincisi hakkında.

Kararın verildiği an kurulumdan önce. Kaydın şekli ve bağları ilk satır yazılmadan karara bağlanıyor. Bu kararın zamanını ve geri alma bedelini mimari kararların neden koddan önce verildiği üzerine yazdığımız yazıda açtık; bu yazı şekli anlatıyor, o yazı zamanı.

Terimi okumak da her zaman yetmiyor. Şekli henüz oturmamış bir kayıtta hangi alanların geleceği yazılı olmadığı için terim bir vaat taşımıyor. Şu an inşa ettiğimiz Secretum tam bu durumda ve kuruluş kararı üzerinde hâlâ çalışıyoruz. Teklifinizde böyle bir satır varsa sormanız gereken şey ürün adı değil, kaydın hangi alanları taşıyacağı ve neye bağlanacağı.

Kaydınızın hangi şekilde duracağına ve neye bağlanacağına koddan önce karar veriyoruz; sistem mimarisi çalışmasında masaya ilk koyduğumuz liste bu kararlardan oluşuyor.