Excel Tablosu Ne Zaman Veritabanına Dönüşmeli? 6 Belirti

Bir tablo dosyası genellikle masum başlar: birkaç sütun, birkaç yüz satır ve iki üç formül. Aylar sonra aynı dosyada onlarca sekme, birbirine bağlı formüller ve ekipteki herkesin bildiği o cümle vardır: “Buraya dokunma, her şey bozulur.” İşte tam bu noktada Excel tablosu ne zaman veritabanına dönüşmeli sorusu gündeme gelir. Çünkü dosyanız artık bir hesaplama aracı değil, farkında olmadan tasarladığınız kötü bir veritabanı gibi çalışmaktadır.

Bu yazımızda elektronik tablodan veritabanına geçiş belirtilerini tek tek ele aldık. Her belirtinin yanında hem tabloda kalarak uygulayabileceğiniz düzeltmeleri hem de Airtable, Google Sheets + Apps Script ve SQLite gibi seçenekleri sizler için karşılaştırdık.

Elektronik Tablo ile Veritabanı Arasındaki Fark Nedir?

Elektronik tablo (spreadsheet), hücre merkezli bir hesaplama tuvalidir. İstediğiniz hücreye istediğiniz veriyi yazar, yanına bir formül eklersiniz. Esnekliği buradan gelir; kırılganlığı da.

Veritabanı (database) ise kayıt merkezlidir. Her tablonun bir şeması, her sütunun bir veri tipi, her kaydın benzersiz bir birincil anahtarı (primary key) vardır. Tarih sütununa “yarın” yazamazsınız, çünkü sistem buna izin vermez.

Asıl fark tek cümleyle şudur: tabloda kuralları siz hatırlarsınız, veritabanında kuralları sistem uygular. Bir tabloda “müşteri numarası boş bırakılmaz” kuralı sadece sizin kafanızdadır; veritabanında bu kural, veriyi kaydetmeyi reddeden bir kısıttır.

Bu ayrımın teknik adı veritabanı normalizasyonudur: her bilgi tek bir yerde saklanır, diğer tablolar ona bağlanır. Microsoft’un kendi belgeleri de bu çizgiyi net çeker; verileri yönetmek için Access mi Excel mi kullanmalı başlıklı destek sayfasında, düz ve tek tablolu veriler için tablonun, ilişkili ve çok kullanıcılı veriler için veritabanının doğru araç olduğu söylenir.

Excel Tablosu Ne Zaman Veritabanına Dönüşmeli?

Aşağıdaki altı belirtiyi fark edilme kolaylığına göre sıraladık: en üstte hiçbir teknik bilgi gerektirmeden gözünüze çarpanlar, aşağıda ise ancak tablonun yapısına bakınca anlaşılan teknik olanlar yer alıyor. Bir belirti tek başına alarm sayılmaz; ikisi üçü bir aradaysa tablonuz sınırını çoktan aşmıştır.

1. Aynı Dosyaya Aynı Anda Birden Fazla Kişi Yazıyorsa

Bu belirtiyi en başa koymamızın nedeni basit: görmek için dosyayı açmanıza bile gerek yok. Klasörde “rapor_final_v3_SON.xlsx” gibi adlar birikmişse ekip zaten sürüm çakışmasıyla boğuşuyordur.

Aynı dosyaya iki kişi yazmaya kalktığında kilitlenme uyarıları, üzerine yazılan satırlar ve kimin hangi kopyayı güncellediğine dair belirsizlik başlar. Bulut tabanlı tablolar bu sancıyı hafifletir, ama ortadan kaldırmaz.

Veritabanları tam olarak bu senaryo için tasarlandı. Kayıt düzeyinde kilitleme ve işlem (transaction) mantığı sayesinde on kişi aynı anda yazsa bile veri tutarlı kalır.

2. Formüller Başka Dosyalara Uzanıyorsa

İkinci belirti de kendini hemen belli eder: dosyayı her açtığınızda karşınıza çıkan “bağlantıları güncellemek istiyor musunuz?” kutusu. Formülleriniz başka bir çalışma kitabına ya da paylaşılan klasördeki bir dosyaya bakıyorsa elinizde kırılgan bir zincir vardır.

Kaynak dosya taşındığında veya adı değiştiğinde bağlantı kopar. Daha sinsi olanı ise şudur: ekranda gördüğünüz değer önbellekten gelir ve güncel olup olmadığını çoğu zaman anlayamazsınız.

Veri birden çok dosyaya yayıldığında tek gerçek kaynak (single source of truth) kavramı ortadan kalkar. Bu, Google Sheets yerine veritabanı kullanma zamanının geldiğini gösteren en somut işaretlerden biridir.

3. Aynı Listeyi İki Ayrı Sayfada Tutuyorsanız

Buradan sonrası biraz daha sessiz ilerler. Ürün listeniz hem “Siparişler” sekmesinde hem “Fiyatlar” sekmesinde duruyorsa, iki kopya bir süre sonra fark ettirmeden birbirinden ayrılır.

Küçük bir kozmetik satıcısının tablosunu düşünün: aynı ürün bir sayfada “Zeytinyağlı Sabun 150 g”, diğerinde “Zeytinyağı Sabunu 150 gr” diye yazılmıştır. Birinde fiyat 214,90 TL iken diğerinde hâlâ geçen sezonun 189,00 TL’si görünür. DÜŞEYARA formülleri de bu noktadan sonra ya yanlış sonuç ya da #YOK hatası döndürür.

İlişkisel tasarımda böyle bir sapma yapısal olarak mümkün değildir: liste tek bir tabloda durur, diğer tablolar o kayda bir ilişkiyle bağlanır. Fiyatı bir kez değiştirirsiniz, her yerde değişmiş olur.

4. Kayıt Numaralarını Elle Yazıyorsanız

Fatura, sipariş ya da başvuru numarasını klavyeyle giriyorsanız aynı numaranın iki kayıtta birden görünmesi an meselesidir. Biçim bozulması ise daha da yaygındır: bir satıra “FTR2026/145”, diğerine “FTR-2026-145” yazılır ve rapor bunları iki ayrı belge sanar.

Sonuç, ay sonunda tutmayan toplamlar ve elle yapılan mutabakatlardır. Küçük işletmeler için basit veritabanı seçenekleri genelde tam bu yüzden gündeme gelir; hepsinin ortak özelliği, kayıt kimliğini kullanıcının insafına bırakmamalarıdır.

Veritabanları sorunu birincil anahtar ve benzersizlik kısıtıyla kökten çözer. Numarayı sistem üretir, tekrarına izin vermez ve hatalı biçimi baştan reddeder.

5. Sütunlar “Katılımcı 1, E-posta 1, Katılımcı 2” Diye Çoğalıyorsa

Son iki belirti artık gözle değil, tablonun şemasına bakarak anlaşılır. Bir eğitim kaydı tablosunda başlık satırının “Katılımcı 1 | E-posta 1 | Katılımcı 2 | E-posta 2 | Katılımcı 3 | E-posta 3” diye sağa doğru uzaması bunun en tanıdık örneğidir.

Tekrar eden sütun grupları, ilişkisel tasarımda birinci normal form ihlali sayılır. Bedeli de hemen ortaya çıkar: hücrelerin büyük bölümü boş kalır, kaç kişinin kaydolduğunu saymak için sütunları tek tek kontrol edersiniz ve dördüncü katılımcı geldiğinde bütün formülleri yeniden yazarsınız.

Doğru yapı sütunu değil satırı çoğaltmaktır: her satır tek bir katılımcıdır ve etkinlik kaydına bir anahtarla bağlanır. Böylece kaç kişi eklenirse eklensin ne şema ne de formül değişir.

6. Tabloyu Makrolar ve Özel Formlar Yönetiyorsa

Listenin sonunda en derin belirti var. VBA düğmeleri, açılır formlar ve “kaydet” butonlarıyla donatılmış bir dosya artık tablo değil, tablo kılığında bir uygulamadır; uygulama katmanı ile depolama katmanı iç içe geçmiştir.

Bunun bedeli ağırdır. Hatalar artık hücrede değil kodda saklanır, dosyaya yalnızca makroyu yazan kişi güvenle dokunabilir ve o kişi ayrıldığında sistem bakımsız kalır.

Tablo Büyüdükçe Hangi Teknik Sınırlara Çarparsınız?

Yukarıdaki belirtiler yapısaldır. Bir de sert duvarlar vardır ve bunlar tartışmaya kapalıdır.

Excel’in satır ve sütun tavanı Microsoft’un resmi belirtimler ve sınırlar sayfasında yayımlanır. Google Sheets tarafında ise sınır satır değil hücre üzerinden işler ve Google bu tavanı zaman içinde kademeli olarak yükseltmektedir; bu yüzden güncel rakamı resmi Workspace duyurularından doğrulamak en sağlıklısıdır.

Gerçekte kimse bu tavanlara çarparak durmaz; çok daha önce yavaşlar. Dosya açılışının yarım dakikayı bulması, her filtrelemede beklemeniz ve yenileme sırasında ekranın donması, elektronik tablodan veritabanına geçiş belirtilerinin en can sıkıcı olanıdır.

Buna bir de tabloların kendine özgü tuhaflıkları eklenir. Uyumluluk uğruna korunan Excel’in 1900 artık yıl hatası, veri doğruluğunun bazen aracın tasarım kararlarına bağlı olduğunu gösteren güzel bir örnektir.

Tablonuzu Veritabanına Nasıl Taşırsınız?

Geçiş “hemen SQL öğrenin” demek değildir. Dört basamaklı bir merdiven düşünün; çoğu ekip için doğru cevap ilk iki basamakta saklıdır.

Basamak 1: Tabloda Kalıp Yapıyı Düzeltmek

Sorun her zaman aracın kendisi değildir; çoğu zaman kurgudur. Tabloda kalarak şunları yapabilirsiniz:

• Her listeyi tek bir sayfada tutun, kopyalamak yerine Power Query ile bağlayın.
• Kritik sütunlara veri doğrulama ekleyin; serbest metin yerine açılır liste kullanın.
• Yinelenen kayıt numaralarını koşullu biçimlendirmeyle otomatik olarak işaretleyin.
• Tekrar eden sütun gruplarını satırlara çevirin, ardından raporlamayı Excel PivotTable ile yapın.
• İlişkileri formülle taklit etmek yerine Excel’in veri modeli üzerinden tanımlayın.

Bu düzeltmeler sizi bir iki yıl daha idare edebilir. Ama veri girenlerin sayısı arttıkça yeniden aynı noktaya gelirsiniz.

Basamak 2: Airtable ve Kodsuz Veritabanları

Excel yerine Airtable kullanmak mantıklı mı sorusunun yanıtı ekibinize bağlıdır. Airtable, tablo görünümünü korur ama arkada gerçek bir kayıt yapısı çalıştırır: alanların veri tipi vardır, kayıtlar birbirine bağlanır, formlarla veri toplanır ve otomasyonlar kurulur. Airtable’ın resmi tanıtım videosunda bu mantığı kısa sürede görebilirsiniz.

Bu yaklaşım, küçük işletmeler için basit veritabanı seçenekleri arasında en hızlı çıkış yoludur; kod yazmadan, birkaç saat içinde çalışır bir yapı kurarsınız. Karşılığında ise plan başına kayıt sınırlarını kabul edersiniz: ücretsiz plan küçük projeler için tasarlanmıştır, veri büyüdükçe ücretli plana geçmeniz gerekir.

Veriyi kendi sunucunuzda tutmak istiyorsanız NocoDB ve Baserow gibi açık kaynak alternatifler benzer bir deneyim sunar. Bu tarz araçlara büyük teknoloji şirketlerine açık kaynak alternatifler yazımızda da yer vermiştik.

Basamak 3: Google Sheets + Apps Script ile Ara Çözüm

Ekibiniz tabloyu bırakmak istemiyorsa ara bir yol var. Google Apps Script, tablonun üzerine kural katmanı eklemenizi sağlar.

Google Sheets Apps Script ile veri doğrulama kurgusunda tipik olarak şunlar yapılır: kayıt numaralarını komut dosyası üretir, form üzerinden gelen satırlar otomatik eklenir, hatalı girişler kaydedilmeden önce reddedilir ve düzenli kontroller zamanlanmış tetikleyicilerle çalıştırılır. Sheets’i verimli kullanmanın diğer yolları için Google E-Tablolar ipuçları rehberimize göz atabilirsiniz.

Bu çözüm ucuzdur ve hızlı kurulur. Ancak unutmayın: altta hâlâ bir tablo vardır, dolayısıyla hücre sınırı ve performans sorunları bir noktada geri gelir.

Basamak 4: SQLite, PostgreSQL ve Access Gibi Gerçek Veritabanları

Veri hem büyük hem de kritikse gerçek bir veritabanı kaçınılmazdır. Seçim, verinin kaç kişiyle ve nasıl paylaşıldığına bağlıdır.

• SQLite: Tek dosyalık, sunucusuz bir veritabanı. Tek kullanıcılı analizler, masaüstü araçları ve yerel veri saklama için idealdir. Resmi belgelerde de hangi durumlarda uygun olduğu açıkça anlatılır; aynı anda tek yazıcıya izin verdiği için yoğun eş zamanlı yazmada tercih edilmez.
• PostgreSQL: Çok kullanıcılı, ağ üzerinden erişilen, uzun ömürlü sistemler için açık kaynak standart. Resmi sitesinde belirtildiği gibi kökleri 1986’ya uzanır ve çekirdek platformda kırk yıla yaklaşan bir aktif geliştirme geçmişi vardır.
• Microsoft Access: Windows ortamında kalmak isteyen, form ve raporlarıyla küçük ölçekli masaüstü çözümü arayan ekipler için hâlâ pratik bir seçenek.

Hangi Çözüm Hangi Duruma Uygun?

Geçişten Önce Hangi Hazırlıkları Yapmalısınız?

Bozuk bir yapıyı olduğu gibi taşırsanız, yeni sistemde de aynı sorunları yaşarsınız. Taşımadan önce şu adımları öneririz:

• Mevcut dosyanın yedeğini alın ve taşıma boyunca dokunmayın.
• Hangi tabloların gerçekten ayrı birer varlık olduğunu belirleyin (müşteri, ürün, sipariş gibi).
• Her tablo için benzersiz bir anahtar tanımlayın; elle yazılan numaraları bırakın.
• Tekrar eden sütun gruplarını satırlara çevirin, yani veriyi taşımadan önce düzleştirin.
• Yazım hatalarını ve yinelenen kayıtları temizleyin; kirli veri yeni sisteme de taşınır.
• Önce tek bir süreçle pilot yapın, çalıştığından emin olduktan sonra tamamını taşıyın.
• Tabloyu tamamen atmayın; raporlama ve hızlı analiz katmanı olarak kullanmaya devam edin.

Sonuç: Tabloyu Ne Zaman Bırakmalısınız?

Excel tablosu ne zaman veritabanına dönüşmeli sorusunun yanıtı aslında sade: tablo hesap yapmak için, veritabanı veriyi saklamak için vardır. Dosyanız hesap yapmayı bırakıp veri saklamaya başladıysa sınır çoktan aşılmıştır.

Karar verirken şu ölçüyü kullanabilirsiniz: veri kaybı, yanlış rapor veya bir kişinin ayrılmasıyla oluşacak bilgi boşluğu sizi endişelendiriyorsa geçiş vakti gelmiştir. Aksi hâlde tabloyu düzeltip yolunuza devam edebilirsiniz.

Eğer bu tarz teknoloji içerikleri ilginizi çekiyorsa, sitemizde yer alan “Notion Nedir? Notion AI Nasıl Kullanılır?” adlı yazımıza da göz atabilirsiniz.