[Razi91]

Pytanie do bazodanowców... Co jest lepsze:
1. Jedna tabela z kolumną-indeksem definiującym ID użytkownika
2. Setki tabel dla każdego użytkownika z osobna

Docelowo użytkowników ma być kilkaset.

#bazydanych #programowanie #heheszki

[cxnmlhuipwetr]

@Razi91: pewnie poczytali sobie o architekturach multi-tenant tylko zaaplikowali to do każdego usera z osobna xD

[Frogof]

@Razi91: @seeksoul: @prezydent_wykopu: @xMAT: @Paczek_w_masle: @3mielu: @michal_kopaczewski: przecież podejście 2 jest do obronienia zależnie od kontekstu i innych wymagań.

[Razi91]

@Frogof niby tak, ale jakby podliczyć wszystkie za i przeciw, to one nie przegrywa. Potencjalne problemy jakie stanowi te rozwiązanie dyskwalifikuje je z użycia. Czekam na konkretne przykłady.

[seeksoul]

@Frogof: podaj 3 przypadki kiedy da się zastosować podejście drugie; takie z życia, biznesowy case'y gdzie można cos takiego zaprogramować

śmiało

[Frogof]

@Razi91: no właśnie to zależy
@seeksoul: chyba jeden przypadek wystarczy żeby rozwiązanie miało racje bytu. Czy zawsze trzeba trzy?:) ale proszę, masz trzy:
1. Inne sla dla różnych klientów
2. Zabezpieczenie przed złymi klientami
3. Wymaganie fizycznej separacji danych od różnych klientów

[Paczek_w_masle]

@Frogof:

3. Wymaganie fizycznej separacji danych od różnych klientów

po co w ogóle coś takiego pchać do jednej bazy/schematu?

[Razi91]

@Frogof:

1. Inne sla dla różnych klientów

Tak, ma to sens, ale w takim rozwiązaniu, gdzie każdemu klientowi stawiasz osobną aplikację, czyli de facto utrzymujesz N instancji tej samej aplikacji.

I wtedy tak, może to być lepsze rozwiązanie, bo awaria jednej bazy nie rozwala innych klientów. Do tego można aktualizować np. tylko

[Frogof]

3. Wymaganie fizycznej separacji danych od różnych klientów

po co w ogóle coś takiego pchać do jednej bazy/schematu?

@Paczek_w_masle: bo operacyjność lepsza? Bo ktoś nie chce mieć nowego endpointa/aclow/connection poola dla każdego klienta? Bo łatwiej odkrywać? Bo jest dużo innych części wspólnych? Bo szybciej/łatwiej postawić na żądanie? Bo lepsze wykorzystanie zasobów? Tak sobie wymyślam - może być dużo

[Frogof]

@Razi91: jak nie chcesz na wszystko to chociaż na to odpisz, naprawdę jestem ciekaw:)

2. Zabezpieczenie przed złymi klientami

Jeżeli musisz to w taki sposób rozwiązać, to znaczy że system jest zaprojektowany jako bardzo awaryjny.

Co zrozumiałeś przez to co napisałem? I jakie jest Twoim zdaniem lepsze rozwiązanie tego problemu?

[Razi91]

@Frogof: Jak masz API zabezpieczone przed floodem, bazę dobrze zorganizowaną, to nie ma potrzeby oddzielać baz danych. Ale tutaj mam JEDNEGO klienta i potencjalnie już widzę że za rok będzie chciał robić np. statystyki między użytkownikami i SIĘ NIE DA tego prosto zrobić, bo każdy ma osobną bazę.

O ile w pewnych przypadkach takie rozwiązanie ma sens, tutaj NIE MA. Widzę same potencjalne przeszkody w przyszłości. I naprawdę: ta baza

[Frogof]

@Razi91: dzieki. Zaznacze tylko ze ja nie pisalem o osobnych bazach, tylko o osobnych tabelach.

Tak czy inaczej - czyli doszedles do tego samego wniosku co ja? :)

Ja na poczatku

[Razi91]

@Frogof: Tylko że zwykle „użytkownicy” są w kontekście tej samej aplikacji, prawda? Zatem cały problem dotyczy organizacji bazy w JEDNEJ APLIKACJI, zatem nie ma mowy o różnych klientach wymagających osobnego traktowania. Swoją drogą to „użytkownik” tu też nie do końca jest rzeczywistym użytkownikiem, ale to detal.

Missclick. Tabele miały być. Ale osobne tabele tym bardziej nie mają sensu. Osobne bazy na osobnych wirtualkach już prędzej.

[Frogof]

@Razi91: nie robilem zadnych zalozen co do tego czym jest uzytkownik, aplikacja tez jest pojemnym pojeciem (proces/instancja/tier/geostamp/globalna). Aplikacja moglaby byc usluga, ktora wystawiasz i tak, rozni klienci mogliby miec rozny poziom sla/supportu/limitow/etc.

I znowu piszesz ze cos nie ma sensu nie podjac zadnych argumentow :D pewnie w pracy masz wiecej czasu zeby dyskutowac, ale nie wiem w jaki sposob jestes w stanie kogokolwiek do czegokolwiek przekonac:)

Mysle, ze to mozemy

[Razi91]

@Frogof: Nie, nie ma sensu dyskutować. Rozumiem twoje argumenty, jednak w tym projekcie nie mają one w ogóle zastosowania (w skrócie: jest jeden serwer, do niego wysyłają dane klienci w sensie komputery, jednej firmy, dane będą wyświetlane na zbiorczych wykresach). Podałem (i inni też) argumenty optujące za jedną tabelką. Jednak jak widzisz, większość komentujących tu jest za podejściem z jedną tabelą. I jak widzisz, nikogo tutaj przekonywać nie musiałem, sami

[Frogof]

@Frogof: Nie, nie ma sensu dyskutować. Rozumiem twoje argumenty

Okej, ale chyba nie rozumiesz na poparcie jakiej tezy je podaje.

jednak w tym projekcie nie mają one w ogóle zastosowania (w skrócie: jest jeden serwer, do niego wysyłają dane klienci w sensie komputery, jednej firmy, dane będą wyświetlane na zbiorczych wykresach). Podałem (i inni też) argumenty optujące za jedną