Aplikacja SasS

Chciałbym w celach treningowych napisać taka aplikacje. Np. niech to będzie serwis samochodowy czy teź gabinet dentystyczny.
Sama aplikacja nie jest jakaś wyszukana - jej pods. funkcjonalność. Chodź o aspekt kont klientów, prezentowania im ich danych, jedna baza. Chciałbym pisać w php stąd wątek tutaj.
Czy hierarchia kont w stylu
Firma
User
UserFirma
Roles
UserRoles
I do KAZDEJ tabeli userId?

Wystarczy wpisać w google dental office database design i wyciągnąć odpowiednie wnioski.

Wystarczy przeczytac moj post.
Chodzi mi o budowę aplikacji SasS a nie jaka db pod gabinet.

Po co chcesz dodawać do każdej tabeli user_id ?

No wlasnie strzelam, staram sie pobudzic dyskusje. Kreujesz aplikacje tego warsztatu i dajesz do niej dostep 19 serwisom samochodowym. To jest jedna i ta sama aplikacja. Ewentualnie dajesz kazdemu subdomenę - tutaj tez mam niejasnosc jak to ma chodzic. User_id by wiedziec kto kreuje dany wpis i by prezentowac danemu zakladowi jego dane.

Czyli w takim razie chcesz stworzyć aplikacje tzn. multi-tenant.
http://stackoverflow.com/questions/13325383/multi-tenant-php-saas-separate-dbs-for-each-client-or-group-them
http://www.innomatic.io/
https://www.slideshare.net/InnomaticPlatform/building-multitenant-and-saas-products-in-php-cloudconf-2015

Dokladnie. Czytalem w sieci zanim zadalem post tutaj.
Tak jak opcja 1 (z id firmy/usera) jest zrozumiala to opcja z oddzielną bazą nie. Zalozmy ze uzyjemy Laravela lub innego mamy plik z db konf. Ten musialby byc inny dla kazdego klienta. I tutaj mam dziure. Jak?
Poczytam o subdomenach :)

Moim zdaniem najlepszym wyjście jest posiadanie bazy per klient. W momencie bootstrapowania aplikacji po subdomenie zaczytujesz odpowiednią bazę.

Wydaje mi się, że posiadanie jednej bazy dla wielu klientów ma dwie głowne wady:

• klient A przez przypadek może zobaczyć dane klienta B. Przy wielu bazach jest mniejsza szansa, bo błąd musiałby być w logice zaczytującej dane do bazy po subdoemenie. Jeżeli masz jedną bazę, to w zapytaniach musisz pilnować warunków where tenant_id = ...
• performance. Załóżmy, że średnio klient ma 1 000 000 rekordów w jakiejś tabelce, a Ty masz 100 klientów... :)

Jeżeli chodzi o samego laravela, to możesz sobie to zrobić np. tak:

function tenantEnv($key, $default)
{
    $url = 'http://tenant.app.com/'; //$_SERVER['host'];

    $parsedUrl = parse_url($url);

    $host = explode('.', $parsedUrl['host']);

    $subdomain = $host[0];

    return env(strtoupper($subdomain) . "_" . $key, $default);
}

i w .env

TENANT_DB_DATABASE=homestead
TENANT_DB_USERNAME=homestead
TENANT_DB_PASSWORD=secret

no i oczywiście podmieniasz w pliku config.php czy tam db.php juz nie pamiętam, funkcję env() na tenantEnv.

Wyjście nr 2, czyli osobny plik .env, np. .env.tenant. Możesz do tego użyc $app->loadEnvironmentFrom('.env.tenant');. Wtedy funkcja env() będzie uzywała tego pliku, który załadujesz. Nie musisz wtedy modyfikowac configów, ale nie wiem gdzie wrzucić to wywołanie, musisz poszukać.

Desu napisał(a):

Moim zdaniem najlepszym wyjście jest posiadanie bazy per klient. W momencie bootstrapowania aplikacji po subdomenie zaczytujesz odpowiednią bazę.

Wydaje mi się, że posiadanie jednej bazy dla wielu klientów ma dwie głowne wady:

• klient A przez przypadek może zobaczyć dane klienta B. Przy wielu bazach jest mniejsza szansa, bo błąd musiałby być w logice zaczytującej dane do bazy po subdoemenie. Jeżeli masz jedną bazę, to w zapytaniach musisz pilnować warunków where tenant_id = ...
• performance. Załóżmy, że średnio klient ma 1 000 000 rekordów w jakiejś tabelce, a Ty masz 100 klientów... :)

Jeżeli chodzi o samego laravela, to możesz sobie to zrobić np. tak:

Kopiuj

function tenantEnv($key, $default)
{
    $url = 'http://tenant.app.com/'; //$_SERVER['host'];

    $parsedUrl = parse_url($url);

    $host = explode('.', $parsedUrl['host']);

    $subdomain = $host[0];

    return env(strtoupper($subdomain) . "_" . $key, $default);
}

i w .env

Kopiuj

TENANT_DB_DATABASE=homestead
TENANT_DB_USERNAME=homestead
TENANT_DB_PASSWORD=secret

no i oczywiście podmieniasz w pliku config.php czy tam db.php juz nie pamiętam, funkcję env() na tenantEnv.

Wyjście nr 2, czyli osobny plik .env, np. .env.tenant. Możesz do tego użyc $app->loadEnvironmentFrom('.env.tenant');. Wtedy funkcja env() będzie uzywała tego pliku, który załadujesz. Nie musisz wtedy modyfikowac configów, ale nie wiem gdzie wrzucić to wywołanie, musisz poszukać.

Ma wady ale najczęściej jest stosowana jedna baza i na pewno nie zdobędzie tylu klientów aby było trzeba to dzielić na wiele baz danych.
Ma obciążenie podobne do zwykłego portalu.

I co, wtedy w kazdej tabeli ma tenant_id? Jak dla mnie bardzo upierdliwe. Lepiej jest to zapakowac do bootstrapa (zaczytywanie odp. bazy) i mieć z glowy. Mielismy to co mowisz u nas w firmie i kompletny niewypał.