Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Selam
https://tenancy.dev/
https://spatie.be/docs/laravel-multitenancy/v3/introduction
https://tenancyforlaravel.com/

böyle paketler mevcüt

Ayrıca
https://www.youtube.com/watch?v=xbKGx3BRYjg

paketsiz şekilde yapılmış forması var ve ben anlayamadım bu yapının tam olarak nerede kullanılacağını.

  • mgsmus bunu yanıtladı.
  • kursatcanciger

    Her bir müşteri için ayrı veri tabanı kullanırsanız:

    Artıları

    • Komple izolasyon sağladığınız için verilerin karışması mümkün değildir.
    • Müşteriye özel olarak veri tabanı genişletilebilir, kaynak arttırılabilir, veri merkezi değiştirilebilir.
    • Rollback gerektiren durumda veri tabanı sadece müşteriye ait olduğu için kolayca rollback yapılabilir.
    • Müşteriye özel veri tabanı değişiklikleri mümkün olur.
    • Kesinti durumunda sadece 1 müşteri etkilenir.
    • Kayıt sayısı ile sorgu süresinin doğru orantılı olduğu durumlarda daha hızlı işlem yapılabilir.

    Eksileri

    • Uygulamadaki güncellemeleri bütün müşterilerinizin veri tabanlarına tek tek yansıtmanız gerekir.
    • Veri tabanı motoru gibi sistemsel güncellemeler yine aynı şekilde tek tek yapılır.
    • Maliyet çok daha fazla olacaktır, müşteri sayısı arttıkça tek veri tabanına göre çok daha fazla artacaktır.
    • Ürünle ilgili toplu istatistiklere erişmek için tüm veri tabanlarından alınan istatistikleri birleştirmeniz gerekecek.
    • Büyük ihtimalle ortak veriler için ayrı, merkezi bir veri tabanına ihtiyacınız olacak yoksa primary key, uuid gibi tüm veri tabanlarında ortak olmasını isteyeceğiniz alanlara sahip olamayacaksınız.

    Tek bir veri tabanı kullanırsanız:

    Artıları

    • Yönetmesi ve güncellemesi kolay olur, maliyeti de çok daha az olur. Tek bir veri tabanı ile çalışmak daha kolaydır.
    • Sistem genelinde tenant farketmeksizin verilere kolay ulaşabilirsiniz, istatistikler çıkarabilirsiniz ya da bunlar için ayrı araç ve yapılar kullanmak zorunda kalmazsınız.
    • Herkesin kullanabileceği verileri ayrı bir yerde tutmak zorunda kalmazsınız. Ürüne ait bir kaydın id'si 13 ise tüm tenantlar için o 13'dür.

    Eksileri

    • Sadece bir müşterinin verilerini geri almanız (rollback) ya da kaldırmanız zor olacaktır.
    • Kayıt sayısı çok daha fazla olacağı için sorgu ve indekslemeri çok daha iyi analiz etmeniz gerekir.
    • Tüm işlemler aynı veri tabanında olacağı için işlemci, ram ve disk kullanımları da artacaktır.
    • Kesintiler tüm müşterilere yansır.

    Buraya eklenecek şeyler vardır mutlaka, ilk aklıma gelenleri yazdım. Daha ayrıntılı bilgi isteyenler araştırabilir. Benim tercihim çok özel bir durum yoksa daima tek bir veri tabanı kullanmaktır. (Doğal olarak, mikroservisler için ayrı oluşturulan veri tabanları buna dahil)

    aghabalaguluzade SaaS bir ürün yaptığınızı düşünün. İnsanlar kaydolup kendi bilgilerini eklemeye başlayacaklar. Bu bilgilerin bir kısmı veri tabanına girecek bir kısmı dosya olarak sisteme eklenecek. Bunları bir şekilde ayırmanız, izole etmeniz gerekiyor ki birbirine karışması, herkes sadece kendi kayıtlarına ulaşabilsin. Buna tenancy (kiracılık) deniyor, tenant (kiracı) da bu sistemi kullanan kullanıcı olmuş oluyor. SaaS üründe zaten ürün size ait, ürünü değil hizmeti satıyorsunuz, yani bir nevi kiracılara kiralıyorsunuz.

      mgsmus Bunları bir şekilde ayırmanız, izole etmeniz gerekiyor ki birbirine karışması, herkes sadece kendi kayıtlarına ulaşabilsin.

      Müşteriler , Ürünler , Personel tüm bu tablolarda kullanıcıya özelmi olmuş oluyor ? normalde ürün tablosunda bir user_id ile bu iş çözülmesi gerekmezmi ? yani her üye olan kullancıya ait tablolarmı oluşuyor ?

        isset Tenant sistemlerde ya her tenant için ayrı ayrı veri tabanları olur (tablo değil yani direkt veri tabanı) ya da tek bir veri tabanı olur ve dediğiniz gibi bir key ile kayıtlar ayrılır. Her iki yöntemin de avantajları dezavantajları var, araştırabilirsiniz.

          mgsmus Tenant sistemler için sizin öneriniz nedir? Ayrı veri tabanları ile çalışmak mı yoksa tek veri tabanı ile çalışmak mı daha kolay olur? Konudaki tenant paketlerinden özellikle tecrübe ettiğiniz ve önerebileceğiniz var mı?
          Bu konudaki düşüncelerinizi öğrenmek isterim.

            kursatcanciger

            Her bir müşteri için ayrı veri tabanı kullanırsanız:

            Artıları

            • Komple izolasyon sağladığınız için verilerin karışması mümkün değildir.
            • Müşteriye özel olarak veri tabanı genişletilebilir, kaynak arttırılabilir, veri merkezi değiştirilebilir.
            • Rollback gerektiren durumda veri tabanı sadece müşteriye ait olduğu için kolayca rollback yapılabilir.
            • Müşteriye özel veri tabanı değişiklikleri mümkün olur.
            • Kesinti durumunda sadece 1 müşteri etkilenir.
            • Kayıt sayısı ile sorgu süresinin doğru orantılı olduğu durumlarda daha hızlı işlem yapılabilir.

            Eksileri

            • Uygulamadaki güncellemeleri bütün müşterilerinizin veri tabanlarına tek tek yansıtmanız gerekir.
            • Veri tabanı motoru gibi sistemsel güncellemeler yine aynı şekilde tek tek yapılır.
            • Maliyet çok daha fazla olacaktır, müşteri sayısı arttıkça tek veri tabanına göre çok daha fazla artacaktır.
            • Ürünle ilgili toplu istatistiklere erişmek için tüm veri tabanlarından alınan istatistikleri birleştirmeniz gerekecek.
            • Büyük ihtimalle ortak veriler için ayrı, merkezi bir veri tabanına ihtiyacınız olacak yoksa primary key, uuid gibi tüm veri tabanlarında ortak olmasını isteyeceğiniz alanlara sahip olamayacaksınız.

            Tek bir veri tabanı kullanırsanız:

            Artıları

            • Yönetmesi ve güncellemesi kolay olur, maliyeti de çok daha az olur. Tek bir veri tabanı ile çalışmak daha kolaydır.
            • Sistem genelinde tenant farketmeksizin verilere kolay ulaşabilirsiniz, istatistikler çıkarabilirsiniz ya da bunlar için ayrı araç ve yapılar kullanmak zorunda kalmazsınız.
            • Herkesin kullanabileceği verileri ayrı bir yerde tutmak zorunda kalmazsınız. Ürüne ait bir kaydın id'si 13 ise tüm tenantlar için o 13'dür.

            Eksileri

            • Sadece bir müşterinin verilerini geri almanız (rollback) ya da kaldırmanız zor olacaktır.
            • Kayıt sayısı çok daha fazla olacağı için sorgu ve indekslemeri çok daha iyi analiz etmeniz gerekir.
            • Tüm işlemler aynı veri tabanında olacağı için işlemci, ram ve disk kullanımları da artacaktır.
            • Kesintiler tüm müşterilere yansır.

            Buraya eklenecek şeyler vardır mutlaka, ilk aklıma gelenleri yazdım. Daha ayrıntılı bilgi isteyenler araştırabilir. Benim tercihim çok özel bir durum yoksa daima tek bir veri tabanı kullanmaktır. (Doğal olarak, mikroservisler için ayrı oluşturulan veri tabanları buna dahil)