facebook
Selamlar,bi proje üzerinde çalışıyoruz, bi noktada takıldık. cloud apartment yönetim sistemi satacağız diyelim. Her apartmanda 10 daire, daire başına 1 kullanıcı var diyelim ve 100 tane farklı apartman var. bu durumda 100 farklı veritabanı mı oluşturmamız gerekiyor ? Bunların yönetimi nasıl olur ?
Selamlar,
bi proje üzerinde çalışıyoruz, bi noktada takıldık.
cloud apartment yönetim sistemi satacağız diyelim. Her apartmanda 10 daire, daire başına 1 kullanıcı var diyelim ve 100 tane farklı apartman var. bu durumda 100 farklı veritabanı mı oluşturmamız gerekiyor ? Bunların yönetimi nasıl olur ?
bi proje üzerinde çalışıyoruz, bi noktada takıldık.
cloud apartment yönetim sistemi satacağız diyelim. Her apartmanda 10 daire, daire başına 1 kullanıcı var diyelim ve 100 tane farklı apartman var. bu durumda 100 farklı veritabanı mı oluşturmamız gerekiyor ? Bunların yönetimi nasıl olur ?
0
şu an nasıl bir veri saklamayı planlıyorsunuz ki her daireye 200 tablo ihtiyaç duyuyorsunuz açıklaman gerekiyor.
tek veritabanı da olabilir, her apt. için de. burada sizin uygulamayı veya ne kadar veriyi nasıl saklayacağınızı (kısaca veri modelini) bilmeden "şöyle ypamak doğru" demek zor.
tek veritabanı da olabilir, her apt. için de. burada sizin uygulamayı veya ne kadar veriyi nasıl saklayacağınızı (kısaca veri modelini) bilmeden "şöyle ypamak doğru" demek zor.
0
cloud tabanli bir hizmet sunacaksaniz bu saas modelinde multi tenant bir mimariye karsilik geliyor diyebiliriz.
Veritabani konusunda uc genel yaklasim var diyebiliriz. Sorunun cevabi da biraz sizin stratejinizle alakali.
1-) Bir tane vertabani instance'a sahip olursunuz ve tum top level master tablolara ClientID verip musterileri birbirinden izole edebilirsiniz. Eger ayni anda farkli musterilere farkli uygulama versiyonlari, ozellikler sunacaksaniz bu model uzun vadede isinize yaramaz.
2-)Baseline olarak bir veratabani tasarimi yapip her yeni gelen musteri icin manuel veya docker benzeri bir containeri otomate ederek on demand deployment yapabilirsiniz. Yani her musteri icin bir veritabani instance olur. Bu senaryonda ilerde musteri birlestirme veya farkli durumlar icin haricten bir adet katalog veritabani tutmaniz tavsiye edilir.
3-) Son olarak shared multi tenant diye bir yaklasim daha var. Bu durumda daha karmasik ancak esnek bir yapi kurabiliyorsunuz. Veritabani lisans vb maliyerleriniz duserken, deployment zorlugunuz artiyor.
Asagidaki makalelere gozatmanizi oneririm:
docs.microsoft.com
Bu makalede ise her bir baslik icin Entity Framework ile yapilmis github ornekleri de var. Mutlaka gozatin derim.
azure.microsoft.com
Veritabani konusunda uc genel yaklasim var diyebiliriz. Sorunun cevabi da biraz sizin stratejinizle alakali.
1-) Bir tane vertabani instance'a sahip olursunuz ve tum top level master tablolara ClientID verip musterileri birbirinden izole edebilirsiniz. Eger ayni anda farkli musterilere farkli uygulama versiyonlari, ozellikler sunacaksaniz bu model uzun vadede isinize yaramaz.
2-)Baseline olarak bir veratabani tasarimi yapip her yeni gelen musteri icin manuel veya docker benzeri bir containeri otomate ederek on demand deployment yapabilirsiniz. Yani her musteri icin bir veritabani instance olur. Bu senaryonda ilerde musteri birlestirme veya farkli durumlar icin haricten bir adet katalog veritabani tutmaniz tavsiye edilir.
3-) Son olarak shared multi tenant diye bir yaklasim daha var. Bu durumda daha karmasik ancak esnek bir yapi kurabiliyorsunuz. Veritabani lisans vb maliyerleriniz duserken, deployment zorlugunuz artiyor.
Asagidaki makalelere gozatmanizi oneririm:
docs.microsoft.com
Bu makalede ise her bir baslik icin Entity Framework ile yapilmis github ornekleri de var. Mutlaka gozatin derim.
azure.microsoft.com
0
apartmanlara bi tablo
dairelere bi tablo (içinde apartman id'sinin olacağı bi alan ile)
kullanıcılara bi tablo (en basidinden apartman ve daire id'lerinin olacağı birer alan ile)
sonra da bunları eşleyerek (left join vs.) ilerleyebilirsiniz.
dairelere bi tablo (içinde apartman id'sinin olacağı bi alan ile)
kullanıcılara bi tablo (en basidinden apartman ve daire id'lerinin olacağı birer alan ile)
sonra da bunları eşleyerek (left join vs.) ilerleyebilirsiniz.
0
200 tablo çok fazla, mutlaka bir yerde yanlış yapıyorsunuz.
İlişkisel veritabanı nedir öncelikle oradan başlayın, veriyi modellemediğiniz için her şeye ayrı tablo açıyorsunuz. Aslında buna gerek yok.
İlişkisel veritabanı nedir öncelikle oradan başlayın, veriyi modellemediğiniz için her şeye ayrı tablo açıyorsunuz. Aslında buna gerek yok.
0
