Dataverse mı SharePoint Listesi mi? Power Apps Veri Kaynağı Seçimi

Power Apps uygulamasında ilk teknik karar veri kaynağıdır ve sonradan değiştirmesi en pahalı karar da budur. SharePoint listesi hızlı başlar, ek lisans istemez; bu yüzden çoğu projede sorgusuz varsayılan olur. Dataverse ise ilişkisel model, satır düzeyi güvenlik ve yaşam döngüsü yönetimi getirir, karşılığında lisans ve disiplin ister. Aşağıda iki seçeneği kayıt hacmi, veri modeli, güvenlik, delegasyon, lisans ve ALM açısından karşılaştırıyor ve proje başında kullanılabilecek bir karar ağacı veriyoruz.

Seçimi belirleyen ölçütler

“Hangisi daha iyi?” sorusunun genel yanıtı yok. Karar, uygulamanın bugünkü hâli için değil iki-üç yıl sonraki hâli için şu sorulara verilen yanıtlarla belirlenir. Bu soruları proje açılışında masaya koyun; altı ay sonra sormak geç kalmaktır:

1. Kayıt hacmi: Ana tablo yılda kaç kayıt üretecek? Uygulama tüm kayıtlar üzerinde mi, yalnız kullanıcının kendi kayıtları üzerinde mi çalışacak?
2. Veri modeli: Birbirine bağlı kaç tablo var? Bire-çok ve çoka-çok ilişkiler, ana-detay formlar (sipariş ve satırları gibi) gerekiyor mu?
3. Güvenlik: Kullanıcılar yalnız kendi kayıtlarını veya kendi departmanlarının kayıtlarını mı görmeli? Bazı alanlar belirli rollerden gizlenmeli mi?
4. Sorgu karmaşıklığı: Arama, çoklu filtre ve toplama büyük veri kümesi üzerinde mi yapılacak?
5. Lisans: Kullanıcıların mevcut Microsoft 365 lisansları uygulamayı kapsıyor mu, premium lisans bütçesi var mı?
6. Yaşam döngüsü: Uygulama geliştirme, test ve üretim ortamları arasında kontrollü taşınacak mı?

SharePoint listesinin güçlü ve zayıf yanları

SharePoint listesi veriyi kullanıcının zaten tanıdığı bir arayüzde saklar: tarayıcıdan görüntülenir ve düzenlenir, Excel’e aktarılır, Power Automate ile kolayca tetiklenir. İzin talebi, demirbaş kaydı, eğitim katılım listesi gibi küçük ve orta ölçekli departman uygulamalarında çoğu zaman yeterlidir. Burada sorun yok.

Sorun belirli bir eşikten sonra başlar ve genellikle üretimde fark edilir:

• Liste görünümü eşiği: Liste milyonlarca öğe taşıyabilir; ama 5.000 öğeyi aşan taramalar engellenir. Sütun indeksleri ve seçici filtreler zorunlu hâle gelir. Ayrıntısı meta veri ve liste görünümü eşiği rehberinde.
• Delegasyon: Delege edilemeyen sorgular yalnız veri satırı sınırı kadar kaydı işler; SharePoint bağlayıcısında Search ve in gibi işlemler delege edilmez. Büyük listede bunun anlamı şudur: kullanıcı bazı kayıtları göremez ve hiçbir hata mesajı almaz. En tehlikeli arıza sessiz olanıdır. Sınırlar ve çözüm kalıpları Power Apps delegasyon rehberinde.
• İlişkiler: Arama (lookup) sütunları basit ilişki kurar; çoka-çok ilişki, kademeli silme ve bütünlük kuralları yoktur. Bir liste görünümündeki arama sütunu sayısı da sınırlıdır.
• Satır düzeyi güvenlik: Kullanıcının yalnız kendi kayıtlarını görmesi uygulamada filtreyle sağlanır. Bu bir güvenlik denetimi değildir; kullanıcı listeye tarayıcıdan doğrudan erişebilir. Gerçek ayrım için öğe düzeyinde devralmayı kırmak gerekir ve bu ölçeklenmez.
• İşlem bütünlüğü: Birden çok listeye yazılan bir kaydın “tümü ya hiçbiri” mantığıyla (transaction) yazılması desteklenmez; yarım kalan yazmaları uygulama tarafında telafi etmeniz gerekir.

Öğe düzeyi izinlerin yönetim yükü SharePoint izin modeli rehberinde ayrıntılı anlatılıyor.

Dataverse’in sağladığı ilişkisel model ve güvenlik

Dataverse, Power Platform’un yönetilen veri tabanıdır. Tablolar, ilişkiler, iş kuralları ve güvenlik aynı katmanda tanımlanır:

• İlişkisel model: Bire-çok ve çoka-çok ilişkiler, ilişki davranışları (kademeli silme, atama), alternatif anahtarlar ve hesaplanan veya toplama sütunları.
• Rol tabanlı güvenlik: Güvenlik rolleri tablo bazında oluşturma, okuma, yazma, silme yetkilerini kullanıcı, iş birimi veya kuruluş kapsamında tanımlar. “Satış temsilcisi yalnız kendi iş biriminin kayıtlarını okur” kuralı veri katmanında uygulanır; uygulama filtresine bağlı değildir.
• Sütun düzeyi güvenlik: Maaş veya kimlik numarası gibi alanlar belirli profillerden gizlenebilir.
• Denetim: Tablo ve sütun bazında değişiklik geçmişi tutulabilir.
• ALM: Tablolar, uygulamalar ve akışlar aynı çözüm (solution) içinde paketlenir ve ortamlar arasında taşınır.
• Delegasyon: Dataverse bağlayıcısı daha geniş bir fonksiyon setini delege eder; büyük tablolarda arama ve filtreleme daha öngörülebilir çalışır.

Bedeli üç kalemdir: premium lisans, kapasite tüketimi ve modelleme disiplini. Dataverse tablosu son kullanıcının tarayıcıda liste gibi açıp düzenlediği bir yer değildir; veri model temelli uygulama, canvas uygulama veya yapıcı (maker) portalı üzerinden düzenlenir. Kullanıcı alışkanlığı değişir. Bunu eğitim planına yazın. Kavramsal tanıtım için Microsoft’un Dataverse dokümantasyonu resmi başlangıç noktasıdır.

Lisans etkisi ve doğrulama

Lisans, karar ağacında çoğu zaman teknik ölçütlerin önüne geçer. Genel çerçeve şöyle: SharePoint gibi standart bağlayıcıları kullanan canvas uygulamaları, Power Apps kullanım hakkı içeren Microsoft 365 lisanslarıyla çalıştırılabilir. Dataverse (Teams için Dataverse dışında) ve premium bağlayıcılar ise uygulamayı kullanan her kullanıcı için premium Power Apps lisansı gerektirir; kullanıcı başına, uygulama başına ve kullandıkça öde gibi modellerden hangilerinin satışta olduğu dönemsel olarak değişir. Teams için Dataverse, Teams içinde çalışan uygulamalara daha sınırlı bir kapsamla sunulur.

Örnek hesap yöntemi: uygulamayı kullanacak kişi sayısını, uygulamanın kaç kişiye açılacağını ve bu kişilerin başka premium uygulama kullanıp kullanmayacağını bir tabloya yazın. Tek bir premium uygulamayı kullanan geniş kitle ile birden çok premium uygulama kullanan dar kitle genellikle farklı lisans modellerine yönelir; hangisinin daha ekonomik olduğunu güncel fiyat listesi söyler. Hesabı her seferinde güncel teklifle yeniden yapın. Geçen yılın fiyatı bugünün kararı değildir.

Üçüncü seçenek Azure SQL Database veya SQL Server’dır. İlişkisel model ve büyük hacim için güçlüdür; ancak SQL bağlayıcısı da premium sınıftadır ve güvenlik modelini uygulama veya veri tabanı tarafında ayrıca kurgulamanız gerekir.

Karşılaştırma tablosu ve karar ağacı

Ölçüt	SharePoint listesi	Dataverse
Kayıt hacmi	Küçük–orta; eşiğe dikkat	Büyük hacimde öngörülebilir
İlişkiler	Basit arama sütunu	1:N, N:N, ilişki davranışları
Satır düzeyi güvenlik	Öğe izni; ölçeklenmez	Rol, iş birimi, sahiplik
Sütun düzeyi güvenlik	Yok	Var
Delegasyon	Sınırlı fonksiyon seti	Daha geniş fonksiyon seti
Lisans	M365 kapsamında olabilir	Premium lisans
ALM	Liste şablonu ve betik	Çözümler ile ortamlar arası
Kullanıcı erişimi	Tarayıcıdan doğrudan	Uygulama üzerinden

Kurumsal iş uygulaması projelerinde karar ağacını şu sırayla yürütüyoruz:

1. Kullanıcılar yalnız yetkili oldukları kayıtları görmeli mi ve bu bir denetim gereği mi? Evet ise Dataverse (veya güvenliği ayrıca kurgulanmış SQL).
2. Ana-detay ilişkiler, çoka-çok bağlar veya kademeli silme gibi ilişki davranışları gerekiyor mu? Evet ise Dataverse.
3. Ana tablo birkaç yıl içinde on binlerce kaydı aşacak ve uygulama tüm kayıtlar üzerinde arama yapacak mı? Evet ise Dataverse; hayır ise SharePoint listesi uygun olabilir.
4. Premium lisans bütçesi yoksa ve ilk üç sorunun yanıtı hayırsa SharePoint listesi; uygulama Teams içinde ve küçük ekipteyse Teams için Dataverse değerlendirilebilir.

Listeyle başlama kararı verildiyse delegasyon kurallarını ilk ekrandan itibaren uygulayın: filtrelenen sütunları indeksleyin, Search yerine StartsWith kullanın, sayaçları uygulamada değil kaynakta hesaplayın. Geliştirme ortamında 50 kayıtla her şey çalışır. Test verisini gerçek hacimde yükleyin.

Listeden Dataverse’e geçiş senaryosu

Sahada sık karşılaştığımız tablo şu: satın alma talep uygulaması SharePoint listesiyle başlamış, kayıt sayısı büyümüş, kullanıcılar “bazı taleplerim görünmüyor” demeye başlamış, üstüne departman bazlı gizlilik ihtiyacı doğmuş. Geçiş sırası:

1. Model: Liste sütunlarını Dataverse tablolarına eşleyin. Seçim sütunları seçim (choice) sütunlarına, arama sütunları ilişkilere dönüşür; tekrarlayan metin alanları ayrı tablolara ayrılabilir.
2. Ortam ve çözüm: Tabloları varsayılan ortamda değil, geliştirme ortamında bir çözüm içinde oluşturun. Ortam yapısı için Power Platform ortam stratejisi rehberine bakın.
3. Veri aktarımı: Power Query tabanlı veri akışlarıyla (dataflows) liste verisini Dataverse tablosuna yükleyin. Arama ilişkileri için önce ana tabloları, sonra ilişkili tabloları aktarın; liste öğe kimliğini eşleme için geçici bir sütunda saklayın.
4. Güvenlik: Güvenlik rollerini ve iş birimlerini tanımlayın, test kullanıcılarıyla doğrulayın. Yönetici hesabıyla test etmeyin.
5. Uygulama ve akışlar: Canvas uygulamadaki veri kaynağını değiştirin; sütun adları ve türleri farklı olduğu için formülleri tek tek gözden geçirin. Listeyi tetikleyici olarak kullanan Power Automate akışları Dataverse tetikleyicileriyle yeniden yazılır.
6. Kesinti planı: Son aktarımdan önce listeyi salt okunur yapın, delta aktarımı yapın ve kayıt sayılarını iki tarafta karşılaştırın. Sayılar tutmuyorsa geçiş bitmemiştir.

Geçişte en çok emeği veri değil, formül ve akış uyarlaması yer. Bu yüzden ilk sürümden kalıcı bir veri modeli beklenen uygulamada baştan Dataverse ile başlamak, sonradan taşımaktan genellikle daha ucuza gelir. Uygulama ve veri modeli tasarımında Power Apps ile iş uygulamaları, platform yönetişiminde low-code danışmanlığı sayfalarımıza göz atabilirsiniz.

Sık sorulan sorular

SharePoint listesi kaç kayda kadar Power Apps için uygundur?

Kesin bir sayı yok. Liste çok sayıda öğe taşıyabilir; belirleyici olan uygulamanın sorgularının delege edilip edilemediği ve görünümlerin 5.000 öğe eşiğine göre tasarlanıp tasarlanmadığıdır.

Uygulamada filtre koymak satır düzeyi güvenlik sağlar mı?

Hayır. Uygulama filtresi yalnız gösterimi kısıtlar; kullanıcı listeye tarayıcıdan veya başka bir araçla doğrudan erişebilir. Gerçek ayrım Dataverse güvenlik rolleri veya öğe izinleriyle sağlanır.

Dataverse kullanmak her zaman premium lisans gerektirir mi?

Genel kural olarak standart Dataverse premium lisans ister; Teams için Dataverse ise Teams içindeki uygulamalara daha sınırlı kapsamla sunulur. Kurallar değişebildiği için güncel lisans kılavuzundan doğrulayın.

Listeden Dataverse’e veri nasıl aktarılır?

Power Query tabanlı veri akışlarıyla liste verisi Dataverse tablolarına yüklenir. İlişkiler için önce ana tablolar aktarılır; eşleme için liste öğe kimliği geçici bir sütunda tutulur.