Veritabanı eğitiminin standart açılış cümlesi — “SQL beş alt dilden oluşur” — üst üste binmiş üç kavramsal yanılgı taşır. Bu yazı üçünü de tek bir tezle çözmeyi deniyor: diskte yalnızca baytlar vardır; dosya, satır, document ve mesaj, o baytlara bakan programların taktığı isimlerdir; ve “dosya sistemi / veritabanı / mesaj kuyruğu” ayrımı bir tür farkı değil, bu isimlendirmenin derecesidir. Tez yeni değil — veri bağımsızlığı (Codd, 1970; ANSI/SPARC, 1975) ve “one size does not fit all” (Stonebraker & Çetintemel, 2005) literatürünün genelleştirilmiş bir okumasıdır. Katkı iddiada değil, çerçevede: beş dil kategorisini bir taksonomi olmaktan çıkarıp bir ölçü aleti haline getirmek.
1. Yanlış açılış cümlesi
Veritabanı derslerinin klasik açılışı bellidir: “SQL beş alt dilden oluşur — DDL, DML, DQL, DCL ve TCL.” Cümle teknik olarak yanlış sayılmaz, ama tarihsel olarak baş aşağıdır.
“Data Description Language” ve “Data Manipulation Language” terimleri, CODASYL'in Data Base Task Group tarafından Nisan 1971 raporunda ortaya konmuştur; aynı rapor schema ve subschema kavramlarını da getirir. Bunlar ilişkisel değil, ağ (network) veri modeli için tanımlanmıştı. Chamberlin ve Boyce'un SEQUEL makalesi ise 1974 tarihlidir. Yani DDL ve DML, SQL doğmadan üç yıl önce, SQL'in rakibi olan bir model için icat edilmişti.
SQL'in resmî tanımı olan ISO/IEC 9075-2, ifadeleri “DDL/DML” diye değil, SQL-schema statements, SQL-data statements, SQL-transaction statements, SQL-session statements gibi sınıflara ayırır. “DQL” ise standartta hiç geçmez; SELECT standart metinde bir veri ifadesidir. Beşli taksonomi, standardın değil pedagojinin ürünüdür.
Apache Cassandra'nın resmî dokümantasyonunda Data Definition ve Data Manipulation diye ayrı bölümler vardır. İşlem teorisi (Gray, 1981) ve erişim denetimi (Saltzer & Schroeder, 1975) zaten en baştan dilden bağımsız formüle edilmiştir.
Bu üç kanıt aynı yöne işaret eder: beş kategori SQL'in malı değildir. Ama düzeltme burada bitmez, çünkü altında iki yanılgı daha vardır. İkincisi: “veritabanı”, “dosya sistemi”, “mesaj kuyruğu” gibi sistem kategorileri sanıldığı kadar keskin değildir. Üçüncüsü ve en derini: bu sistemlerin üzerinde çalıştığını iddia ettiği birimler — dosya, satır, document, mesaj — de gerçek varlıklar değildir.
Aşağıda en dipten başlayıp yukarı çıkacağız: önce bayta, sonra isimlere, sonra sınır ihlallerine, en sonunda spektruma.
2. Katman sıfır: “dosya” diye bir şey yok
2.1 Tez
Diskte fiziksel olarak var olan tek şey baytlardır — adresleri belli, sıralı, yorumsuz baytlar. “Dosya” dediğimiz şey, bu baytlardan bir grubuna, dosya sistemi denen bir bilgisayar programının verdiği grup ismidir. Dosya diskte yaşamaz; dosya sisteminin yorumunda yaşar. Aynı diski dosya sistemi sürücüsü olmadan okuyan bir program hiçbir dosya görmez; yalnızca bayt görür.
Aynı işlem her katmanda tekrarlanır. MongoDB, bir grup baytı alır ve onlara “document”, document gruplarına “collection” der. SQL motoru, bir grup bayta “cell”, cell dizilerine “row”, row kümelerine “table” der. Kafka aynı baytlara “message” ve “topic” der. Bunların hiçbiri bayta bir şey eklemez; hepsi bir adlandırmadan ibarettir. Ontolojik olarak document, row, dosya ve mesaj aynı statüdedir: yorumlayıcı bir programın baytlara yapıştırdığı etiketler.
2.2 Yorum yığını özyinelemelidir
Bu bakış, iç içe geçmiş güzel bir tabloyu görünür kılar. SQLite, dosya sisteminin gözünden tek bir dosyadır. Ama aynı baytlara SQLite'ın gözünden bakınca dosya kaybolur; yerine tablolar ve satırlar belirir. İçindeki bir satır, SQLite'ın evreninde, dosyanın dosya sistemi evreninde oynadığı rolün aynısını oynar: adreslenebilir, isimlendirilmiş bir bayt grubu.
Hangi ismin “gerçek” olduğu sorusunun cevabı yoktur, çünkü ikisi de gerçek değildir — gerçek olan alttaki baytlardır, isimler bakan programa aittir.
2.3 Tarihsel kanıt: dosyasız diskler gerçekten var
Düşünce deneyini bir adım ileri götürelim: bir diski, üzerinde dosya sistemi olmadan, doğrudan satır–sütun saklayacak biçimde formatlasak, o disk hiç dosya içermezdi. Dosya yokluğundan değil; o baytlara “dosya” diyecek programın yokluğundan.
Bu bir düşünce deneyi olarak kalmadı:
- Raw device. Oracle onlarca yıl veritabanı dosyalarını doğrudan ham blok aygıtları üzerinde tuttu; dosya sistemi devre dışıydı. Bu yetenek ancak 11g Release 2 ile kurulum araçlarından kaldırıldı (Oracle 12c deprecated & desupported features). Yıllarca üretimde koşan bu diskler, tanım gereği hiçbir dosya içermiyordu.
- IBM System/38 (1978). Frank Soltis'in tek düzeyli bellek mimarisinde diskte geleneksel anlamda bir dosya sistemi yoktu: kütüphaneler içinde adlandırılmış nesneler ve işletim sistemine gömülü ilişkisel bir veritabanı vardı — hem de SQL/DS ve DB2'den önce (IT Jungle).
- Unix'in katkısı zaten “dosyayı boşaltmak”tı. Ritchie ve Thompson'ın 1974 tarihli The UNIX Time-Sharing System makalesinin radikal yanı, kendinden önceki kayıt-yapılı (record-oriented) dosya modellerini terk edip dosyayı yorumsuz bir bayt dizisi olarak tanımlamasıydı. “Everything is a file” sloganı bir felsefe değil, bir isim uzayı stratejisidir — ve Plan 9 bunu açıkça öyle formüle etti (Pike ve ark., The Use of Name Spaces in Plan 9).
Dosya, diskin bir özelliği değil, bakışın bir özelliğidir.
2.4 Bu tez aslında ne kadar yeni? (Hiç değil)
Burada söylenen şeyin akademik adı vardır: veri bağımsızlığı (data independence). Codd'un 1970 tarihli A Relational Model of Data for Large Shared Data Banks makalesinin ve onu takip eden ANSI/SPARC üç-şema mimarisinin (1975) tam kalbi budur: iç (internal) katman — baytlar, sayfalar, indeksler — ile kavramsal (conceptual) katman — tablolar, satırlar — ve dış (external) görünüm katmanı birbirinden bağımsızdır.
“Satır diye bir şey diskte yoktur; o mantıksal şemanın bir kavramıdır” cümlesi elli yıldır veritabanı ders kitaplarının ilk bölümüdür. Bu yazının yaptığı tek şey, cümleyi bir adım genelleştirmek: dosya da aynı statüdedir.
Bu genelleme de yabancı değil. İşletim sistemi literatüründe dosya sistemi zaten açıkça “blok aygıtı üzerine bir soyutlama katmanı” olarak tanımlanır. Programlama dilleri teorisindeki karşılığı ise doğrudan: veri ile onun yorumu (interpretation) ayrımı, bitlerin bir tip/yorum olmadan anlamı yoktur ilkesi. İsimlendirme ve bağlama (binding) meselesinin kendisi de sistem literatüründe başlı başına bir konudur — Saltzer'ın Naming and Binding of Objects (1978) çalışması bunun kanonik metnidir.
Yani tez orijinal değil; taşınmış. Veritabanı topluluğunun kendi katmanları için söylediği şeyi, tüm depolama yığınına uygulamak.
2.5 İtiraz: bayt da bir yorum değil mi?
Evet. Manyetik akı geçişleri, NAND hücrelerindeki yük seviyeleri, hata düzeltme kodları, 512B/4K sektör çevirileri — “bayt” da bir soyutlamadır ve altında başka katmanlar vardır. Kaplumbağalar aşağı doğru devam eder.
Bu yazının baytta durmasının nedeni ontolojik değil, pragmatiktir: bayt, yazılım katmanının altındaki en alt seviyedir ve evrensel, kararlı, adreslenebilir bir referans çerçevesi sunar. Yığındaki her yorumlayıcı program aynı bayt uzayına bakar; bunun altındaki katmanlar donanıma göre değişir ve yazılım için erişilemezdir. Bayt, tartışmanın ortak paydası olduğu için sıfır noktası seçilmiştir — mutlak gerçeklik olduğu için değil.
3. İsimlendirmenin grameri: beş soru
Peki bu yorum programları birbirinden nasıl ayrılır? İşte burada beş katman devreye girer — ama artık onları doğru yerden tanımlayabiliriz. DDL, DML, DQL, DCL ve TCL, baytların üzerine isim koyan her programın cevaplamak zorunda olduğu beş sorudur.
| # | Soru | SQL etiketi | Teorik dayanak |
|---|---|---|---|
| 1 | İsimler nasıl tanımlanır? Hangi bayt gruplarına ne denecek — tablo, collection, topic, dizin. Veriyi değil, adlandırma şemasını değiştirir; bir isim uzayı kurar. | CREATE ALTER DROP | Şema kavramı — CODASYL DBTG (1971); ANSI/SPARC kavramsal katman (1975) |
| 2 | İsimlendirilen baytlar nasıl değiştirilir? Bir durumdan diğerine geçiş. | INSERT UPDATE DELETE | Durum dönüşümü — Gray (1981) |
| 3 | İsim üzerinden baytlara nasıl ulaşılır? Sorgu dediğimiz şey, isimden bayta giden yolun tarifidir. | SELECT | Veri bağımsızlığı ve ilişkisel cebir — Codd (1970) |
| 4 | Hangi isimlere kim dokunabilir? Yetki daima isim düzeyinde verilir; kimse “0x4A3F'ten itibaren 512 bayt” üzerine yetki tanımlamaz. | GRANT REVOKE | Erişim matrisi — Saltzer & Schroeder (1975) |
| 5 | Değişiklikler ne zaman “gerçek” olur? İsimlerin gösterdiği baytların, bakan herkese aynı anda ve tutarlı görünme garantisi. | COMMIT ROLLBACK | İşlem kavramı, ACID — Gray (1981) |
Dördüncü sorunun cevabındaki ayrıntı tüm tezin özetidir: yetki isme verilir, adrese değil. Çünkü koruma sistemi de baytları değil, isimleri görür.
Bu sorular SQL'e ait değildir, çünkü isimlendirme işleminin kendisine aittir:
| Soru | SQL | MongoDB | POSIX dosya sistemi | Kafka | Amazon S3 |
|---|---|---|---|---|---|
| İsim tanımı (DDL) | CREATE TABLE | createCollection | mkdir, creat | topic oluşturma | bucket oluşturma |
| Değiştirme (DML) | INSERT/UPDATE | insertOne | write, unlink | produce | PutObject |
| Okuma (DQL) | SELECT | find, aggregate | read, readdir | consume + offset | GetObject |
| Yetki (DCL) | GRANT | grantRolesToUser | chmod, ACL | topic ACL | IAM politikası |
| Tutarlılık (TCL) | COMMIT | commitTransaction | fsync, journal | idempotent producer | nesne başına atomiklik |
SQL yalnızca bu sorulara akademik etiketler yapıştıran ilk yaygın standarttır. Katmanlar evrenseldir, çünkü baytlara isim verip o isimler üzerinden işlem yapan her program, ister istemez bir isim tanımlama, değiştirme, okuma, yetkilendirme ve tutarlılık cevabına sahip olmak zorundadır — cevap “neredeyse hiç” olsa bile.
Bu bölümün epistemik statüsü. Bölüm 1'in tarihsel kanıtları sağlamdır: DDL/DML terimlerinin CODASYL kökeni belgelidir, standardın taksonomisi bellidir. Ama beşliyi açıkça “evrensel veri dili anatomisi” ilan eden kanonik bir makale bildiğim kadarıyla yoktur. Buradaki genelleme, fiilî pratiğin teorileştirilmesidir: sektör bunu yapar (Cassandra'nın DDL/DML bölümleri, MongoDB'nin işlem API'si, Kafka'nın ACL'leri), ama nadiren böyle adlandırır.
4. Sınır ihlalleri: ampirik kanıt
Temel bir kez böyle atılınca, sistem kategorilerinin neden keskin olamayacağı kendiliğinden çıkar: madem dosya sistemi, veritabanı ve mesaj kuyruğu aynı baytlar üzerinde çalışan eşit statüde isimlendirme programlarıdır, aralarındaki fark türsel değil, derecelidir — beş soruya verdikleri cevapların zenginlik derecesi.
Bu, veri sistemleri literatüründe de eski bir tartışmadır. Stonebraker ve Çetintemel'in “One Size Fits All”: An Idea Whose Time Has Come and Gone (ICDE 2005) makalesi, bu kategorilerin doğa yasası değil mühendislik ödünleşimi olduğunu savunur. Martin Kleppmann'ın Turning the Database Inside-Out tezi ve Jay Kreps'in The Log yazısı, log/kuyruk/veritabanı ayrımının aynı temel yapının — sıralı bir bayt log'unun — farklı görünümleri olduğunu açıkça işler. Kafka'nın kendi öz-tanımı olan “dağıtık commit log” da doğrudan bu düşünceden gelir.
Sınır ihlalleri bunu sürekli hatırlatır:
| Sistem | Etiketi | İhlal |
|---|---|---|
| Transactional NTFS | dosya sistemi | Dosya işlemlerine tam atomiklik (5. soru) ekledi — Registry ve SQL ile aynı işlemde. Microsoft, karmaşıklığı ve düşük ilgi nedeniyle alternatifleri “şiddetle tavsiye” ediyor. ↗ |
| ZFS | dosya sistemi | Mimarisinin göbeğindeki DMU katmanı, tanımı gereği genel amaçlı bir işlemsel nesne deposudur; POSIX dosya sistemi (ZPL) bunun üzerine geçirilmiş yalnızca bir görünümdür. ↗ |
| Btrfs | dosya sistemi | Doğrudan bir veritabanı tekniği üzerine kurulu: gölgelemeli (copy-on-write) B-ağaçları ve klonlar. ↗ |
| SQLite | veritabanı | Dışarıdan tek dosya; ama kendi ölçümlerine göre ~10 KB'lık blob'ları ayrı dosyalar halinde okuyup yazmaktan %35 daha hızlı ve ~%20 daha az yer kaplıyor. Yani “dosya sistemi işini” dosya sisteminden iyi yapıyor. ↗ |
| Kafka | mesaj kuyruğu | Mesajları diske yazar, süresiz saklar, offset'le geriye okutur, üstüne SQL sorgusu attırır. “Kafka bir veritabanı mıdır?” tartışması sektörde ciddi ciddi yapılmıştır. ↗ |
| PostgreSQL | veritabanı | LISTEN/NOTIFY ve SKIP LOCKED ile kuyruk gibi çalıştırılır. Postgres'in kendi dokümantasyonu SKIP LOCKED'ı açıkça “kuyruk benzeri tablo”lardaki çoklu tüketici senaryosu için önerir. ↗ |
| WinFS | dosya sistemi | Microsoft'un dosya sistemini doğrudan bir ilişkisel veritabanı üzerine kurma girişimi (2003–2006). Terk edildi, ama niyet açıktı. ↗ |
| BeFS | dosya sistemi | İndekslenmiş öznitelikler ve sorgu desteği — 90'larda bir dosya sistemine gömülmüş DQL. ↗ |
Tersinden bakalım: bir graf veritabanından işlem (transaction) desteğini çekin; kalan şey, işaretçili bayt gruplarına isim veren, atomiklik vaat etmeyen bir program — yani işlevsel olarak bir dosya sistemi. Kuyruk gibi davranan veritabanları ve veritabanı gibi davranan kuyruklar aynı anda vardır — çünkü hepsi aynı şeyi yapıyordur: baytlara isim vermek ve beş soruya cevap üretmek.
“Bu hâlâ bir dosya sistemi mi, yoksa hiyerarşik isimlerle çalışan bir veritabanı mı?” sorusu cevapsızdır, çünkü kötü sorulmuştur. Değişen şey sistemin türü değil, beşinci soruya verdiği cevabın gücüdür.
5. İdeal kutuplar ve spektrum
Kategorileri tümden atmak yerine, onları fizikteki ideal gaz gibi kullanabiliriz: gerçekte var olmayan ama gerçek olanı ölçmeye yarayan kutuplar. Sosyal bilimlerdeki karşılığı Max Weber'in ideal tip (Idealtypus) kavramıdır — betimleyici değil, karşılaştırma ölçütü olarak kurgulanmış saf biçim.
- İdeal dosya sistemi, isimlendirmeyi asgaride tutar: baytlara yalnızca adres ve ad verir, içeriğe anlam yüklemez. İsim şeması sığdır, okuma isme değil adrese yakındır, tutarlılık vaadi zayıftır.
- İdeal veritabanı, isimlendirmeyi azamiye çıkarır: baytların içine kadar iner, her parçaya ad verir (satır, sütun, hücre), isimler üzerinde zengin bir cebir kurar, isim düzeyinde ince yetki ve katı tutarlılık sunar.
- İdeal mesaj kuyruğu, isimlendirmeyi zamana bağlar: bir bayt grubunun ismi (mesaj), asıl anlamını üretildiği ve tüketildiği anlar arasındaki yolculukta bulur; saklamak değil aktarmak esastır, sorgu bilerek zayıftır, tutarlılık “kaç kez teslim edildi” biçimine bürünür.
Gerçek sistemler bu üç köşenin gerdiği yüzeyin içinde durur.
SQLite, DB köşesinden FS köşesine sarkar: dışarıdan tek dosya, içeriden tam bir isim evreni. ZFS, FS köşesinden DB'ye doğru tutarlılık kolunu uzatır. Kafka, MQ köşesinden DB'ye epey yol almıştır. Redis üçünün ortasında gezinir.
Hiçbir gerçek sistem köşelerin tam üstüne oturmaz; oturmaya çalışan da genellikle işe yaramaz, çünkü gerçek iş yükleri saf değildir. Stonebraker'ın argümanı tam olarak buydu.
6. Beş soru, bir ölçü aleti olarak
Beş katmanın asıl değeri, taksonomi olarak değil ölçüm aracı olarak kullanılmasındadır. Bir sistemin isim şeması ne kadar derin (DDL), isim cebiri ne kadar zengin (DQL), tutarlılık vaadi ne kadar katı (TCL) — bu cevaplar, sistemin spektrumdaki koordinatını pazarlama etiketinden çok daha güvenilir biçimde verir.
Böylece “Bu bir veritabanı mıdır?” evet/hayır sorusu olmaktan çıkar ve şuna dönüşür:
Baytlara ne derinlikte isim veriyor ve o isimlere ne vaat ediyor?
Pratikte bunu bir kontrol listesi olarak kullanabilirsiniz:
| Soru | Ne aranır | Zayıf uç | Güçlü uç |
|---|---|---|---|
| DDL | isim şemasının derinliği | tek düzey, tipsiz ad | iç içe, tipli, kısıtlı şema |
| DML | değişikliğin taneciği | tümünü değiştir/sil | alan düzeyinde kısmi güncelleme |
| DQL | isim cebirinin gücü | tam adla getir | filtreleme, birleştirme, toplama |
| DCL | yetkinin çözünürlüğü | hep-veya-hiç | satır/sütun düzeyinde politika |
| TCL | vaadin katılığı | en-iyi çaba | çok-nesneli serileştirilebilir işlem |
7. İtirazlar ve sınırlar
Bu çerçeve her şeyi açıklamaz; açıkladığından fazlasını iddia ederse yanlış olur.
- İndirgemecilik riski. “Hepsi baytlara isim vermek” doğrudur ama yetersizdir. Bir sistemin performans karakteristiği — erişim örüntüsü, indeks yapısı, önbellek davranışı, dayanıklılık maliyeti — beş sorunun cevabından türetilemez. B-ağacı ile LSM-ağacı arasındaki fark bu çerçevede görünmez, ama üretimde her şeyi belirler.
- Dağıtık boyut eksik. Beş soru tek düğüm varsayar. Çoğaltma, bölümlenme ve CAP ödünleşimleri ayrı bir eksendir; “TCL” başlığı bunları taşıyacak kadar geniş değildir.
- Kategoriler işe yaramaz demiyoruz. “Veritabanı” sözcüğü bir spektrum bölgesine işaret eden yararlı bir kısayoldur. Sorun sözcüğün kendisi değil, onun doğal bir tür sanılmasıdır.
- Bölüm 3'ün statüsü farklıdır. Beş sorunun evrenselliği, bu yazıda tarihsel bir belgeyle değil, tümevarımla savunuluyor. Karşı örnek bulmak mümkün olabilir — bulunursa çerçeve düzeltilmelidir.
8. Pratik değeri
Bu üç katlı bakışın — aslolan bayt, isimler yorum, kategoriler spektrum — somut getirileri vardır.
Birincisi, transfer edilebilir bilgi üretir. Beş soruyu kavrayan biri, hiç görmediği bir sistemin dokümantasyonunu açtığında ne arayacağını bilir: baytlara hangi isimleri veriyor, isimleri nasıl değiştiriyor ve okuyor, kim dokunabiliyor, ne vaat ediyor. Sistem kendine ne derse desin, sorular aynıdır.
İkincisi, hata ayıklamada ve veri kurtarmada zihni özgürleştirir. “Dosya bozuldu” cümlesi, bayt bakışında “isimlendirme programı bu baytları artık yorumlayamıyor” demektir — baytlar hâlâ oradadır. Bozuk bir SQLite dosyasını hex editörle açıp satırları elle çıkarmak, ya da silinen bir dosyayı diskten ham okuma ile kurtarmak, ancak isimlerin yorum, baytların gerçek olduğunu bilen birine doğal gelir.
Üçüncüsü, sistem seçimini etiketten kurtarır. “Bize bir mesaj kuyruğu lazım” eksik bir cümledir; doğrusu “bize baytları şu derinlikte isimlendiren, şu kadar saklayan, şu teslimat garantisini veren bir nokta lazım” demektir. Bu tarif yapıldığında cevabın illa MQ etiketli bir üründen gelmesi gerekmediği — belki eldeki PostgreSQL'in SKIP LOCKED ile o noktaya zaten oturduğu — görünür olur.
Dördüncüsü, tasarım rehberidir. Kendi veri katmanınızı tasarlıyorsanız yapacağınız iş bellidir: baytlara bir isim şeması giydirmek ve beş soruya bilinçli cevaplar vermek. Hangi köşeye yakın duracağınızı ve hangi soruyu bilerek zayıf cevaplayacağınızı baştan yazmak, “biraz ondan biraz bundan” olmayı kusur değil tasarım kararı olarak sahiplenmenizi sağlar.
9. Sonuç
DDL, DML, DQL, DCL ve TCL'yi SQL'in alt dilleri sanmak, alfabeyi Türkçenin icadı sanmaya benzer — ve bunun tarihsel kanıtı nettir: terimler 1971'de, SQL'den üç yıl önce, başka bir veri modeli için doğdu.
Ama düzeltme zinciri orada bitmez. Katmanlar SQL'in değil, isimlendirme işleminin kendisinindir. Kategoriler doğa yasası değil, bir spektrum üzerine çizilmiş çizgilerdir. Ve o spektrumdaki bütün sistemlerin yaptığı iş, özünde tektir: adresleri belli bir grup bayta isim vermek ve o isimler üzerinden beş soruya cevap üretmek.
Dosya, satır, document, mesaj — hepsi bakan programın gözündedir. Diskte hiçbiri yoktur.
Diskte yalnızca baytlar vardır; ve aslolan bayttır.
Kaynakça
Temel metinler
- Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. CACM 13(6), 377–387. doi:10.1145/362384.362685
- CODASYL Data Base Task Group (1971). April 1971 Report — DDL/DML terimlerinin ve schema/subschema kavramlarının kaynağı. Genel bakış · ACM yeniden basımı
- Chamberlin, D. D. & Boyce, R. F. (1974). SEQUEL: A Structured English Query Language. SIGFIDET '74. doi:10.1145/800296.811515
- ANSI/X3/SPARC Study Group on DBMS (1975). Interim Report — üç-şema mimarisi. Genel bakış
- ISO/IEC 9075-2:2016, Database languages — SQL — Part 2: Foundation. ISO kaydı · standardın 16 parçası
İsimlendirme, dosya ve soyutlama
- Ritchie, D. M. & Thompson, K. (1974). The UNIX Time-Sharing System. CACM 17(7). doi:10.1145/361011.361061
- Saltzer, J. H. (1978). Naming and Binding of Objects. LNCS 60. PDF
- Pike, R. ve ark. (1993). The Use of Name Spaces in Plan 9. Metin
- Soltis, F. — IBM System/38 ve tek düzeyli bellek. Biyografi · System/38'in gömülü veritabanı
İşlem ve koruma
- Gray, J. (1981). The Transaction Concept: Virtues and Limitations. Tandem TR 81.3. PDF
- Saltzer, J. H. & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Proc. IEEE 63(9). Metin
Sınırların bulanıklığı
- Stonebraker, M. & Çetintemel, U. (2005). “One Size Fits All”: An Idea Whose Time Has Come and Gone. ICDE 2005. PDF
- Kreps, J. (2013). The Log. LinkedIn Engineering
- Kleppmann, M. (2015). Turning the Database Inside-Out. Confluent
- Kleppmann, M. (2018). Is Kafka a Database? Kafka Summit SF. Sunum notları
- Rodeh, O. (2008). B-trees, shadowing, and clones. ACM TOS 3(4). doi:10.1145/1326542.1326544
- Rodeh, O., Bacik, J. & Mason, C. (2013). BTRFS: The Linux B-Tree Filesystem. ACM TOS 9(3). doi:10.1145/2501620.2501623
- Bonwick, J. (2007). ZFS: Rampant Layering Violation? Arşiv kopyası
- Giampaolo, D. (1999). Practical File System Design with the Be File System. PDF
Ürün belgeleri
- Microsoft. Alternatives to using Transactional NTFS. MS Learn
- SQLite. 35% Faster Than The Filesystem · SQLite As An Application File Format
- PostgreSQL. SELECT — The Locking Clause · NOTIFY
- Apache Cassandra. Data Definition · Data Manipulation
- Oracle. Deprecated and Desupported Features for Oracle Database 12c
- Microsoft. WinFS
- Weber, M. — ideal tip (Idealtypus)