Forum
Aktif konular
Üyeler
Kurallar
Arama
Veri Tabanı Yaklaşımı [Şube/Bayi] (Fikir Teatisi) Veri Tabanı Yaklaşımı [Şube/Bayi] (Fikir Teatisi)
-
2019 dan beri geliştirdiğim bir projem var. (C# Windorm + MSSQL Database)
Hali hazırda 400'e yakın işletme tarafından kullanılıyor.
Firmaların kahir ekseriyeti projeyi local sunucu (MSSQL Server) üzerinden kullanıyor.
Firmaların müşteri dataları, alacakları, servisleri, stokları gibi verileri yönetiliyor proje üzerinden.Şimdi projeyi farklı bir noktaya getirmem gerekiyor. Kurumsal bir firma şubeleri için projemize talip oldu.
Yanlız istedikleri şey proje üzerinde radikal değişiklik gerektiriyor.
Şubeler kendi datalarına erişebilecekler. Ancak genel merkezdekiler şubelerin tüm datalarına erişebilecekler.Burada aklımda iki temel yaklaşım var.
Ya projeyi komple değiştirip herbir tabloya SubeID gibi bir tanımlama yaparak tüm CRUD işlemlerini elden geçirmem gerekecek.ya da şubelerin databaselerine bağlanıp (ki tüm db ler tek sunucuda barındırılacak) ayrı ayrı raporlama yapan
ayrı bir arayüz geliştirmem gerekecek.Çok kararsızım.
Bana bu konuda fikir verebilir misiniz?
Şimdiden teşekkürler.
-
Tüm veri tabanlarını saat başı tek bir verş tabanında güncelleme yapsan ve tek bir db üzerinden ilerlesen olmazmı?
-
Asayisci bunu yazdı
2019 dan beri geliştirdiğim bir projem var. (C# Windorm + MSSQL Database)
Hali hazırda 400'e yakın işletme tarafından kullanılıyor.
Firmaların kahir ekseriyeti projeyi local sunucu (MSSQL Server) üzerinden kullanıyor.
Firmaların müşteri dataları, alacakları, servisleri, stokları gibi verileri yönetiliyor proje üzerinden.Şimdi projeyi farklı bir noktaya getirmem gerekiyor. Kurumsal bir firma şubeleri için projemize talip oldu.
Yanlız istedikleri şey proje üzerinde radikal değişiklik gerektiriyor.
Şubeler kendi datalarına erişebilecekler. Ancak genel merkezdekiler şubelerin tüm datalarına erişebilecekler.Burada aklımda iki temel yaklaşım var.
Ya projeyi komple değiştirip herbir tabloya SubeID gibi bir tanımlama yaparak tüm CRUD işlemlerini elden geçirmem gerekecek.ya da şubelerin databaselerine bağlanıp (ki tüm db ler tek sunucuda barındırılacak) ayrı ayrı raporlama yapan
ayrı bir arayüz geliştirmem gerekecek.Çok kararsızım.
Bana bu konuda fikir verebilir misiniz?
Şimdiden teşekkürler.
Ben olsam şube yapısını inşa ederim komple fakat mevcut şubeleri ayrı dbler üzerinden yürütmeye devam ederim. Bir servis yazarak cronda fark yedek alarak genel merkez db ye basarım ki genel merkez tüm dataya erişir. Bu sana ne kazandırır yarın başka bir müşteri gelir şubelerde diğer şubelerin stoklarını görsün müşteri kartları ortak olsun vs derse daha kolay devreye alırsın bu işi yaparken şube işlemlerini yetki rol yapısıyla birleştir ki ileride uğraşma 😀 bu bilgiler db yapısı localde çalışıyor esasına göre verilmiştir. Db sunucuda çalışacaksa yapı tercihi daha farklı olur
trooper tarafından 30/Eyl/23 20:55 tarihinde düzenlenmiştir -
Şahsen bende şube yapısı yapardım sube_id diyerek
Yada şuanki yapıyı bozmadan API kodlarsın şubenin interneti bile giderse localden devam eder db eşitle diye bir buton koyarsın interneti gelince veya direkt cron yaparsın her gece çalışır
Tabi alacağın paraya göre değişir ki büyük ihtimal alacağın para bu yapıyı yazmaya değecektir diye düşünüyorum
-
Basit gibi gözüksede uğraştırır.
Özellikle winform elini ayağını biraz bağlar. Yeniden yazsan netcore da web tabanlı işler çok daha kolay olurdu :)Şimdi program en başta monolitik bir mimari ve buna görede DB tasarlanmış. Her durumda db değişiklik gerekecek. SubeID ve (şuan kullanmasanda ilerde lazım olacak) 2-3 alan daha ekle.
Bu saatten sonra micro mimariye veya dağınık veritanına çeviremezsin, bir çok sorunu beraberinde getirir bu. (time-out, delay, senkson sorunları vs vs vs)
Önerim; DB server merkezde olsun ama db server önüne bir api koy. Eski mantıkla formlar doğrudan db bağlanmasın. clientler sorguları apiye göndersin, api doğrudan db ile konuşsun ve ona göre yanıt dönsün. Bu güvenlik, yetkilendirme, loglamada vb. çok işine yarar. Ayrıca client/talep yoğunluğunda redis gibi kuyruklama/cache yapısı eklemen daha kolay olur. db server yormazsın.
Burada yine başka sorun; şubede internet kesildi, ne olacak? ki bizim ülkede bu sıklıkla olur. Clientlar çalışmaya devam etmesi için cache db koyacak mısın? gibi birçok cevaplanması gereken sorularda olacaktır.
-
hocam öneriler çok iyi hatta kafamda toz bulutu oluşturacak kadar iyi hepsi için teşekkür ediyorum.
fakat şöyle de bi problem var. hali hazırda projeyi kullanan firmalar da aynı kanaldan güncelleme alıyor.
şöyle ki ben yeni bir sürüm çıkardığımda sunucuya atıyorum. versiyon numarası değişikliğinde client tarafı bunu fark edip
otomatik güncelleme yapıyor.
bu projede hakkari deki local db kullanan adam da aynı exe yi kullanıyor, tekirdağ daki iki farklı ofiste kullandıkları için bulut db kullanan adam da aynı exe yi kullanıyor.
api vs devreye girdiğinde ben şube yapısı kullanan müşteriler için ayrı bir versiyon çıkarmam gerekecek.
bu ileride programa yapacak olduğumuz yeni modülleri her iki sürüm için (şube yapısı olan firmalar / local db kullanan klasik firmalar) ayrı ayrı derleme yapmam gerekecek
bu da zaman alıcı bi durum.
-
Eski çalışan sisteme dokunma. Şubesiz olarak çalışan şirketlerde tüm işleyiş aynen devam etsin.
Şubeli olarak kullanmak isteyen şirket için gerekli değişiklikleri yap. Tek bir merkezi veritabanı olsun. Diğerleri dediğin gibi şube_id ile veri yazsınlar.
Özetle yazılımının 2 versiyonu olsun. Bir tanesi eski versiyon diğeri şubeli olan yeni versiyon. Yeni versiyonu iyice geliştirip zaman içinde hepsini yeni versiyona güncellersin.
İsimlendirme kurallarına ayrıca dikkat etmelisin. SubeID yazmak yerine TenantId veya tenant_id şeklinde ingilizce isimlendirmeler daha uygun olur.
-
realtime db , cacheleme sıstemı vs ıle kullan , yapıyı degıstırme , mıkro servısle gelıstır , localsunucuyu işlemlerde cache gibi kullan hocam .
kredı kartı poslar gun sonu ıslemı alıp acıp kapama gıbı ıslemlerde verının ana servera gonderıdılgını farze ederek kurgu yapılabılır .
bırde en basıt yontem her zaman en ıyı yontemdır.
Genelde aklına ilk gelenı yap , surece gore kendı kendını şekillendiriyor olacaktır.
Ben de hep bu şekilde oluyor
hipokondriyak tarafından 01/Eki/23 11:10 tarihinde düzenlenmiştir -
Hocam yapmışken CompanyId ve OfficeCode ile çoklu şube gibi çoklu şirket yapısında kurup projeyi saas kafasıyla geliştirirsen daha iyi olur.
-
Hocam hatta nosql olarak Couchbase kullanabilirsin community sürümü var. Sql endpoint ile sql yazarak nosql çözümü kullanabilirsin.
-
Asayisci bunu yazdı
hocam öneriler çok iyi hatta kafamda toz bulutu oluşturacak kadar iyi hepsi için teşekkür ediyorum.
fakat şöyle de bi problem var. hali hazırda projeyi kullanan firmalar da aynı kanaldan güncelleme alıyor.
şöyle ki ben yeni bir sürüm çıkardığımda sunucuya atıyorum. versiyon numarası değişikliğinde client tarafı bunu fark edip
otomatik güncelleme yapıyor.
bu projede hakkari deki local db kullanan adam da aynı exe yi kullanıyor, tekirdağ daki iki farklı ofiste kullandıkları için bulut db kullanan adam da aynı exe yi kullanıyor.
api vs devreye girdiğinde ben şube yapısı kullanan müşteriler için ayrı bir versiyon çıkarmam gerekecek.
bu ileride programa yapacak olduğumuz yeni modülleri her iki sürüm için (şube yapısı olan firmalar / local db kullanan klasik firmalar) ayrı ayrı derleme yapmam gerekecek
bu da zaman alıcı bi durum.
Bu işin asıl doğrusu hiçbir clientın db ye direk erişimi olmaması gerekir fakat genelde kervan yolda düzülür kafası olduğu için başlangıçta bunlar planlanmıyor. Db önüne bi servis inşa etmiş olsaydın db servisini eski yeni sorgulara veri dönecek şekilde güncellerdin problem olmazdı. Genel merkez anlık şube datası ister anlık stok kasa durumu satış hacmi vs vs o yüzden günlük işleri kısa gecikmeli localden basabilmen için servis şart
trooper tarafından 01/Eki/23 15:02 tarihinde düzenlenmiştir
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla