POWER APPS’TE VERİ KAYNAĞI SEÇİMİ: SHAREPOİNT, EXCEL, SQL YAKLAŞIMI

Power Apps ile hızlıca uygulama geliştirmeye başladığınızda ilk büyük karar genellikle şudur: Veriyi nereye koyacağım? SharePoint listeleri mi, Excel dosyaları mı, yoksa kurumsal bir SQL altyapısı mı? Bu seçim, sadece “bağlanır mı bağlanmaz mı” sorusunu değil; performansı, güvenliği, sürdürülebilirliği ve ekiplerin çalışma biçimini doğrudan belirler.

Doğru veri kaynağı, uygulamanın ölçeğine ve kullanım senaryosuna göre değişir. Bazı projelerde SharePoint, hız ve yönetilebilirlik açısından ideal iken; bazı senaryolarda Excel, sadece geçici bir köprü çözüm olarak kalmalıdır. SQL ise doğru kurgulanırsa yüksek hacim, ilişkisel bütünlük ve raporlama ihtiyaçlarında güçlü bir omurga sağlar.

Bu makalede Power Apps’te veri kaynağı seçimi için pratik bir yaklaşım sunacağız: Kriter seti oluşturacak, SharePoint–Excel–SQL seçeneklerini güçlü/zayıf yönleriyle kıyaslayacak ve gerçekçi örneklerle hangi durumda hangi yolu seçmenin daha doğru olacağını ele alacağız.

Power Apps’te Veri Kaynağı Seçimi İçin Temel Kriterler

Seçimi sağlıklı yapmak için önce kriterleri netleştirmek gerekir. Tek bir “en iyi” seçenek yoktur; uygulamanın kullanıcı sayısı, veri hacmi, güvenlik gereksinimi ve kurumun operasyonel olgunluğu seçimde belirleyicidir. Buradaki hedef, bugünü kurtaran değil; 6–12 ay sonra da taşınabilir, izlenebilir ve yönetilebilir bir yapı kurmaktır.

Kullanım Senaryosunu Ölçülebilir Hale Getirin

“Kaç kayıt var?” ve “kaç kullanıcı aynı anda kullanacak?” soruları, seçimde ilk filtreyi oluşturur. Örneğin 5.000 kaydı filtreleyen tek kullanıcı ile 200 kullanıcının aynı anda 200.000 kaydı sorguladığı bir senaryo aynı altyapı ile sağlıklı çalışmaz. Ayrıca ekranların hangi hızda yanıt vermesi gerektiğini (ör. 1–2 saniye) ve hangi işlemlerin yoğun olacağını (listeleme mi, yazma mı) belirlemek gerekir.

Toplam Sahip Olma Maliyeti ve Operasyonel Yük

Excel düşük bariyerli görünür, SharePoint yönetilebilirlik sunar, SQL ise güçlüdür; ancak her birinin bakım yükü farklıdır. İzin yönetimi, yedekleme, şema değişikliği, versiyonlama, izleme gibi konuların kimde olduğu netleşmelidir. Kurum içinde DBA/BT desteği yoksa SQL’e geçiş doğru olsa bile operasyonel olarak zorlayıcı olabilir.

Güvenlik, Yetkilendirme ve Denetim İhtiyacı

Kritik iş verileri söz konusuysa, “kim hangi kaydı gördü/değiştirdi?” sorusunun izlenebilir olması önem kazanır. SharePoint’te liste/dosya izinleri hızlıdır; SQL’de rol tabanlı güvenlik ve denetim daha kontrollü kurgulanır. Power Apps tarafında ise seçilen bağlayıcının kimlik doğrulama modeli (ör. Azure AD), veri erişim politikaları ve ortam (environment) yönetimi bu kararın parçasıdır.

• Veri hacmi ve performans gereksinimi
• Eşzamanlı kullanım ve kilitlenme riskleri
• Yetki modeli ve denetim (audit) beklentisi
• Şema değişikliği, bakım, yedekleme sorumluluğu
• Raporlama, entegrasyon ve kurumsal standartlar

SharePoint: Hızlı Kurulum, Yönetilebilirlik ve Delegasyon Dengesi

SharePoint listeleri, Microsoft 365 ekosisteminde hızlı başlamak için güçlü bir seçenektir. Özellikle departman uygulamalarında, süreç takibinde ve orta ölçekli veri gereksinimlerinde iyi bir denge sunar. Ancak SharePoint ile Power Apps çalışırken delegasyon sınırları ve liste tasarımı kritik hale gelir.

Liste Tasarımı, İndeks ve Alan Tipleri

İyi tasarlanmış bir liste, performansın yarısını çözer. Çok satırlı metin alanlarını gereksiz yere kullanmak, tek alana “birden fazla bilgi” doldurmak veya filtrelenen sütunlarda indeks olmaması, uygulama büyüdükçe sorun yaratır. Kayıt sayısı arttıkça, filtre ve sıralama yapılan alanlar için indeks planlamak gerekir.

Delegasyon Sınırları ve Sorgu Desenleri

Power Apps’te bazı fonksiyonlar ve ifadeler veri kaynağına devredilemez. Bu durumda uygulama, yalnızca belirli sayıda kaydı istemciye çekip işlem yapar ve sonuçlar eksik/yanıltıcı olabilir. SharePoint’te delegasyon uyumlu filtreleme ve sıralama desenleri tercih edilmelidir. Bu, “çalışıyor gibi görünen ama yanlış sonuç veren” riskli uygulamaları engeller.

// SharePoint listesinde delegasyon dostu filtreleme örneği (Power Fx)
Set(varStatus, "Onaylandı");
ClearCollect(
  colItems,
  SortByColumns(
    Filter(Tasks, Status = varStatus && CreatedBy.Email = User().Email),
    "Created",
    Descending
  )
);

SharePoint tarafında liste görünümü limitleri ve büyük listelerde sorgu planı da önemlidir. Liste büyüdükçe, ekran açılışında “tüm listeyi çekme” yaklaşımı yerine, arama/filtre parametrelerini önce kullanıcıdan almak daha sağlıklı bir deneyim sunar.

Excel: Hızlı Prototip, Düşük Bariyer; Ancak Sınırlar Net

Excel, iş birimlerinin en alışkın olduğu veri deposudur. Power Apps ile Excel tablolarına bağlanmak, basit kayıt listeleri ve deneme amaçlı prototiplerde işe yarar. Fakat Excel, çoğu kurumsal senaryoda “kalıcı veri katmanı” olmaktan çok, geçiş dönemi aracıdır.

Tablo Yapısı ve Veri Kalitesi

Power Apps Excel’e bağlanırken “Tablo (Table)” formatını bekler. Serbest hücre düzeni, birleşik hücreler, farklı veri tipleri, boş satır/sütunlar ve tutarsız başlıklar; uygulama tarafında hatalara ve performans sorunlarına yol açar. Excel kullanılacaksa tek bir “ana tablo” mantığıyla, açık alan adları ve tutarlı veri tipleriyle ilerlemek gerekir.

Eşzamanlı Düzenleme ve Kilitlenme Riskleri

Excel dosyası OneDrive/SharePoint üzerinde olsa bile, yüksek eşzamanlı kullanımda kilitlenme ve senkron sorunları oluşabilir. Ayrıca büyüyen veri hacmi, dosya boyutunu artırır; bu da bağlantı gecikmesi ve hata oranını yükseltir. Bu nedenle Excel’i “az kullanıcı + az kayıt + kısa ömür” çerçevesinde konumlandırmak en güvenlisidir.

Excel’le devam etmeniz gereken durumlarda, veri güncelleme işlemlerini sınırlandırmak ve yazma operasyonlarını minimize etmek iyi bir strateji olabilir. Örneğin salt okunur katalog verisi gibi senaryolarda Excel daha az risk taşır.

SQL: Yüksek Performans, İlişkisel Model ve Kurumsal Entegrasyon

SQL (SQL Server veya Azure SQL) tercih edildiğinde, veri katmanı daha kurumsal bir zemine taşınır. İlişkisel model, referans bütünlüğü, indeksleme ve sorgu optimizasyonu ile ölçeklenebilir bir yapı kurmak mümkün olur. Bununla birlikte, bağlantı mimarisi (özellikle şirket içi ağ) ve güvenlik tasarımı baştan planlanmalıdır.

Gateway, Ağ Topolojisi ve Bağlantı Stratejisi

On-prem SQL kullanılıyorsa çoğu durumda On-premises data gateway gerekir. Gateway’in konumu, yük dengeleme yaklaşımı ve erişim izinleri planlanmadığında “bağlanıyor ama yavaş” veya “zaman zaman kopuyor” problemleri ortaya çıkabilir. Azure SQL gibi bulut seçeneklerinde ise ağ güvenliği (ör. private endpoint), IP kısıtları ve kimlik doğrulama yöntemi belirleyicidir.

Güvenlik, Yetki Modeli ve Veri Erişim Katmanı

SQL tarafında doğrudan tabloya yazmak yerine, ihtiyaç durumuna göre view veya stored procedure üzerinden erişim yaklaşımı tercih edilir. Böylece veri erişimi kontrollü olur, uygulama mantığı daha temiz kalır. Ayrıca alan bazlı maskeleme, rol tabanlı yetkilendirme ve kayıt seviyesinde filtreleme gibi gereksinimler SQL’de daha sistematik uygulanabilir.

-- SQL Server tarafında uygulama erişimi için örnek view
CREATE VIEW dbo.vw_RequestSummary AS
SELECT
  r.RequestId,
  r.Title,
  r.Status,
  r.CreatedAt,
  u.DisplayName AS CreatedByName
FROM dbo.Requests r
JOIN dbo.Users u ON u.UserId = r.CreatedByUserId;

-- Performans için filtrelenen alanlarda indeks örneği
CREATE INDEX IX_Requests_Status_CreatedAt ON dbo.Requests(Status, CreatedAt);

Power Apps’te SQL ile çalışırken, ekranlarda gereksiz geniş sorgular yerine amaç odaklı veri çekmek, sayfalama (pagination) ve arama parametreleriyle ilerlemek iyi sonuç verir. Ayrıca yazma işlemlerinde hata yakalama ve kullanıcıya anlaşılır mesajlar göstermek, destek yükünü azaltır.

SharePoint vs Excel vs SQL: Pratik Karşılaştırma ve Karar Matrisi

Karşılaştırmayı “özellik listesi” gibi değil, hedeflenen kullanımın gereksinimleri üzerinden okumak gerekir. Aşağıdaki özet, tipik senaryolarda karar vermeyi kolaylaştırır:

• Hızlı departman uygulaması: SharePoint çoğu zaman en pratik başlangıçtır.
• Prototip / kısa ömür: Excel, kontrollü kapsamda kabul edilebilir.
• Yüksek hacim ve entegrasyon: SQL, kurumsal standartlarda daha sağlamdır.
• Yetki ve denetim: SQL avantajlı; SharePoint orta seviyede; Excel sınırlıdır.
• Bakım ve BT bağımlılığı: SharePoint düşük-orta; SQL orta-yüksek; Excel “gizli maliyet” doğurabilir.

Bu kararları verirken, Power Apps’in bazı davranışları da hesaba katılmalıdır. Örneğin “tek ekranda çok sayıda kontrol + ağır veri çekimi” yaklaşımı, veri kaynağı ne olursa olsun performansı düşürür. Veri kaynağı seçimi, ekran tasarımı ve sorgu deseniyle birlikte düşünülmelidir.

Hibrit Yaklaşımlar: Tek Kaynak Yerine Akıllı Bölümleme

Gerçek hayatta çoğu uygulama tek bir veri kaynağıyla bitmez. Bir yanda kurumsal SQL, diğer yanda SharePoint dokümanları veya referans listeleri olabilir. Burada amaç; her veriyi tek yere taşımak değil, doğru veriyi doğru yerde tutmaktır. Hibrit mimari, doğru sınırlar çizildiğinde hem geliştirme hızını hem de sürdürülebilirliği artırır.

Hibrit Mimari Örnekleri

Örneğin onay akışlarının kayıtları SQL’de dururken; ek dokümanlar SharePoint doküman kütüphanesinde saklanabilir. Ya da sık değişmeyen referans veriler SharePoint’te tutulurken, işlem verileri SQL’de yönetilebilir. Bu ayrım, hem performansı hem de yetki yönetimini sadeleştirir.

Geçiş Stratejisi: Excel’den SharePoint/SQL’e Evrim

Birçok ekip Excel ile başlar, sonra ihtiyaç büyüdükçe SharePoint’e, daha sonra SQL’e taşınır. Bu geçiş planlı yapılırsa sorunsuzdur: alan adlarını standardize etmek, veri tiplerini netleştirmek, benzersiz kimlik (ID) yaklaşımını erken belirlemek ve taşınabilir bir veri modeli kurmak kritik adımlardır.

Bu tür karar ve geçiş planlarını uygulamalı şekilde öğrenmek isterseniz Power Apps eğitimi içeriğine göz atabilir, veri modeli ve entegrasyon konularında örnek senaryolar üzerinden ilerleyebilirsiniz.

Uygulanabilir Kontrol Listesi ve İyi Uygulamalar

Son olarak, seçimi hızlandıran ve sonradan “keşke” demeyi azaltan bir kontrol listesi paylaşalım. Bu liste, ister SharePoint ister SQL olsun, veri katmanının Power Apps ile uyumlu kalmasına yardımcı olur.

Kontrol Listesi

• Filtre/sıralama yapılan alanlar belirlendi ve performans planı çıkarıldı.
• Alan adları, veri tipleri ve zorunlu alanlar netleştirildi.
• Yetkilendirme modeli (kim, neyi görür/yazar) belgelendi.
• Hata yönetimi ve kullanıcı mesajları standardize edildi.
• Veri büyümesi için 6–12 aylık tahmin yapıldı.

Pilot, İzleme ve İyileştirme

İlk sürümü küçük bir pilot grupla yayına almak, gerçek kullanım verisi toplamanızı sağlar. Hangi ekranların yavaşladığı, hangi sorguların pahalı olduğu, kullanıcıların hangi alanlarda hata yaptığı gibi sinyaller, doğru veri kaynağı kararını da doğrular. Gerektiğinde “aşamalı iyileştirme” yaklaşımıyla SharePoint’te indeksleme, SQL’de view/indeks optimizasyonu veya Excel’den taşınma planı devreye alınabilir.

Özetle; Power Apps’te veri kaynağı seçimi, sadece teknik bir bağlantı kararı değildir. Performans, güvenlik, bakım ve ekip kapasitesi birlikte düşünülürse, uygulama büyüdükçe de stabil kalan bir temel oluşturabilirsiniz.