Crm Laravel + db

Odpowiedz Nowy wątek
2019-05-12 21:19
0

Cześć !
Mam taki oto zgryz. Przygotowuje system CRM dla klienta i postanowiłem oprzeć to o laravel. Problem polega na tym, że nie wiem jaki "format" bazy zastosować. Podpowiedzcie co będzie lepsze:
a) PostgreSQL
b) baza główna + bazy klienckie.
CRM będzie opierał się o klientów głównych, którzy będą mieć podklientow. Ilości jednych i drugich - bez ograniczeń. Każdy klient główny w swoich zasobach będzie mieć kilka tabel.
Dajcie znać co będzie lepsze- czy pakowanie wszystkiego do jednego worka czy dla każdego klienta głównego osobne bazy?

Pozostało 580 znaków

2019-05-12 21:57
0

Podpunkt A jest w jakiś sposób niekompatybilny z podpunktem B? ;-]

Tak czy siak: multitenancy można realizować na wiele sposobów - każdy z nich ma swoje wady i zalety; myślę, że najlepiej będzie - jako że już kojarzysz termin - abyś sam sobie poczytał o sposobach realizacji i wybrał ten, który spasuje Ci najlepiej :-)


Pozostało 580 znaków

2019-05-12 22:06
1

Dajcie znać co będzie lepsze- czy pakowanie wszystkiego do jednego worka czy dla każdego klienta głównego osobne bazy?

Koniecznie oddzielna baza dla każdego klienta. Możesz mieć wspólny code base dla wszystkich klientów, ale koniecznie oddzielna baza. Powodów jest dużo, ale trzy główne, to:

  1. W razie wycieku danych, wyciekają Ci dane tylko jednego klienta, a nie dwudziestu.
  2. Nie ma ryzyka, że klient A zobaczy dane klienta B. Dopisywanie do każdego zapytanie where tenant_id = X to gwóźdź w dupie. Można o tym zapomnieć, znacznie łatwiej jest wczytać oddzielną konfigurację bazy przy podnoszeniu aplikacji (np. po sub domenie).
  3. Performance. Dwudziestu klientów w jednej bazie będzie dużo mniej wydajne, bo ilość rekordów bardzo szybko wymknie się spod kontroli. Poza tym znacznie trudniej będzie Ci skalować jedną wielką bazę niż dwadzieścia mniejszych. Niektórzy klienci z jakiegoś powodu mogą chcieć mieć bazę u siebie. Jeżeli masz aplikację zaprojektowaną baza per klient, to implementacja tego wymagania jest trywialna. Gorzej jak tego nie przewidziałeś.

CRM będzie opierał się o klientów głównych, którzy będą mieć podklientow.

Nie bardzo rozumiem ten punkt, możesz doprecyzować?

Dwudziestu klientów w jednej bazie będzie dużo mniej wydajne, bo ilość rekordów bardzo szybko wymknie się spod kontroli. partycjonowanie tabel to zdaje się wynaleziono już kilkadziesiąt lat temu ;-) - Patryk27 2019-05-12 22:07
@Patryk27: chodzi o to, że miałbyś jedną bazę (i scheme), klucz tenant_id i partycjonował po tym właśnie kluczu? Wiesz może jak wygląda performance bazy partycjonowanej vs oddzielnej bazy, bez tenant_id? Domyślam się, że performance jest lepszy, niż gdyby to wszystko trzymać razem, ale ciekawi mnie czy jest z grubsza taki sam jak w przypadku posiadania całkowicie oddzielnych baz. - Desu 2019-05-12 22:14
Pewien nie jestem (nie miałem okazji tworzyć takiego systemu niestety), lecz dokumentacja np. MySQLa wspomina, że partycjonowanie horyzontalne tworzy fizycznie odrębne tabele dla każdego klucza (https://dev.mysql.com/doc/ref[...]en/partitioning-overview.html), więc przypuszczałbym, że nawet jeśli będzie jakaś różnica, to niezauważalna. - Patryk27 2019-05-12 23:07

Pozostało 580 znaków

2019-05-13 10:26
0

Ok, dzięki za informację.
To jeszcze jedno. W jaki sposób przechowywać dane do poszczególnych baz?

W pliku configuracyjnm srodowiska .env masz w laraverze i w katalogu config/db masz tam chyba do dopisania polaczenia do baz. I uzywaj MySql - fporzo 2019-05-17 13:27

Pozostało 580 znaków

2019-05-13 11:54
1

To już zależy od Ciebie. Jeżeli dla każdego klienta stawiasz to na oddzielnym serwerze, to nie musisz dzielić configu. Jeżeli masz jeden serwer, to możesz zrobić pliki na zasadzie:
config_klient_abc.yml i wczytywać po subdomenie. Czyli do config_ doklejasz nazwę klienta i tam trzymasz dane do bazy. Tutaj możesz się popisać kreatywnością :P Możesz też mieć jedną baze, ale oddzielne schematy dla każde klienta, wtedy credentiale masz jedne, ale scheme masz nazwaną klient_a, klient_b, klient_c.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0