Konta użytkowników na serwerze z wieloma bazami danych

Kiedyś zadałem podobne pytanie, ale w innym kontekście i zabrakło odpowiedzi.

Piszę sobie aplikację webową przeznaczoną dla firm i ich pracowników, która będzie korzystać z wielu baz danych (każda firma == niezależna baza danych). Wszystkie bazy będą jednak w obrębie jednego serwera baz danych.
Każda baza danych (firma) będzie miała "właściciela", który będzie nadawał dostępy do tej firmy innym użytkownikom.
Użytkownik może nie mieć dostępu do żadnej firmy (ktoś założył sobie jedynie konto na platformie i nie dostał uprawnień do żadnej firmy) lub mieć dostęp do jednej lub wielu firm (w zależności które firmy nadały mu dostęp).
User, który dostał dostęp do firmy A nie może mieć dostępu do danych firmy B (to chyba oczywiste).

Informacje o użytkownikach, dostępach, uprawnieniach, rolach etc. będą przechowywane w niezależnej bazie konfiguracyjnej (być może na niezależnym serwerze).
Przy zalogowaniu się do aplikacji user wybiera firmę do której chce się zalogować (do której ma dostęp) i otrzymuje JWT m.in. z informacją o ID/nazwie bazy do której ma dostęp.
Gdy chce pobrać jakieś dane do wyświetlenia to nazwa bazy danych pobierana jest z JWT i API zwraca odpowiednie dane.

Pytanie: czy jest sens niezależnie robić dla każdego użytkownika niezależne konto w bazie danych czyli każde połączenie z bazą danych byłoby z niezależnego konta użytkownika. Dzięki temu można dodatkowo zrobić zabezpieczenie, aby dany user miał dostęp tylko do wybranych baz danych.
Jednak będzie to wymagać dodatkowego nakładu pracy oraz w samej bazie danych (serwerze bazy danych) będę miał zdublowaną informację o userach.
Pytanie czy jest sens i czy to jest praktykowane?

A może zamiast robić konto na serwerze baz danych dla każdego użytkownika robić konto dla każdej firmy z dostępem tylko do tej firmy. Czyli jak mam dwie firmy A i B oraz 3 userów to na serwerze baz danych utworzę dwóch userów do łączenia się z każdą firmą niezależnie (jednego dla firmy A a drugiego dla firmy B) i user, który chce się połączyć z firmą A będzie logował się z konta dla tej firmy.
Dzięki temu będę miał mniej kont na serwerze.

Co o tym myślicie? Jakie jest wasze zdanie i podejście?

Jak dla mnie to w przypadku kiedy jeden user może mieć dostęp do wielu firm (w rzeczywistości do wielu baz), cały pomysł aby każda firma miała osobną bazę jest mocno na wyrost, nie mówiąc już o tym aby każdy user łączył się z bazą na własnym haśle. Przecież nie będziesz dawał userom dostępu wprost do bazy a przez twoje oprogramowanie.

abrakadaber napisał(a):

Jak dla mnie to w przypadku kiedy jeden user może mieć dostęp do wielu firm (w rzeczywistości do wielu baz), cały pomysł aby każda firma miała osobną bazę jest mocno na wyrost, nie mówiąc już o tym aby każdy user łączył się z bazą na własnym haśle. Przecież nie będziesz dawał userom dostępu wprost do bazy a przez twoje oprogramowanie.

Bazy muszą być osobno dla każdej firmy - z tego się już nie wycofam z uwagi na zbyt dużą liczbę danych wrażliwych (dane osobowe etc.).
User w danej chwili może mieć dostęp tylko do jednej bazy danych (jak ma dostęp do większej liczby baz to może się przełączyć, ale w danej chwili dostęp jest tylko do jednej z nich).
Hasło użytkownika może być takie samo dla wszystkich userów - nie będzie dostępne publicznie.

Poczytaj o tym. https://learn.microsoft.com/en-us/ef/core/miscellaneous/multitenancy
Trochę w dół zjedź do Multiple databases and connection strings :D

gswidwa1 napisał(a):

Poczytaj o tym. https://learn.microsoft.com/en-us/ef/core/miscellaneous/multitenancy
Trochę w dół zjedź do Multiple databases and connection strings :D

A na co mam zwrócić uwagę?

Wykorzystaj multitenant jak zaproponował @gswidwa1. Możesz tak skonfigurować, że dla każdego klienta będzie osobna schema w bazie danych albo kompletnie osobna baza danych.
W jednym projekcie korzystać z podejścia schema per klient, zaś w innym mamy wspólną schemę i w tabelach jest kolumna tenant, gdzie jest odpowiednie id dla konkretnego klienta. Wynika to z tego, że user ma jedno konto w apce i może korzystać z systemów wielu klientów.

@Kofcio:

zadałeś pytanie w dziale C# ale myślisz na poziomie bazy

@gswidwa1:
odpowiedział na poziomie EF frameworku (to lepsze myślenie)
Nadajecie w zupełnie innych częstotliwościach.

Ostatni raz userów na indywidualnych loginach do bazy, to widziałem ze 20 lat temu na jakimś Interbase i aplikacja zupełnie a-obiektowa, jakies szycie spagetti na GUI, sypiące Generałami Protekszynami, może Delphi
Przy obiektowym layerze nad bazą danych nawet nie umiem sobie tego wyobrazić. Nic się "nie dodaje", cache, buforowanie, sesje, pula połączeń, nic...

Przy designie obiektowym radykalnie zmienia się myślenie, która warstwa ma "dać odpór" i obronić dane, co więcej, nad tabelą dajmy na to Customers prawa można przydzielać funkcjonalnie (działy, kanały sprzedaży), a nie tylko pionowo do całej tabeli masz / nie masz

Kofcio napisał(a):

Każda baza danych (firma) będzie miała "właściciela", który będzie nadawał dostępy do tej firmy innym użytkownikom.
Użytkownik może nie mieć dostępu do żadnej firmy (ktoś założył sobie jedynie konto na platformie i nie dostał uprawnień do żadnej firmy) lub mieć dostęp do jednej lub wielu firm (w zależności które firmy nadały mu dostęp).
User, który dostał dostęp do firmy A nie może mieć dostępu do danych firmy B (to chyba oczywiste).

Informacje o użytkownikach, dostępach, uprawnieniach, rolach etc. będą przechowywane w niezależnej bazie konfiguracyjnej (być może na niezależnym serwerze).

Dla mnie RZECZYWISTA autoryzacja zachodzi w konkretnej pojedynczej bazie, z opowieści wynika, że w tej centralnej jest tylko autentykacja, i tak naprawdę nie musiała być oparta o bazę danych, a np o jakies LDAP-y, cokolwiek.

Co o tym myślicie? Jakie jest wasze zdanie i podejście?

Moje zdanie jest, że umysłowo bardzo skaczesz po warstwach i poziomach, dużo epizodycznych pomysłów implementacyjnych, mało planowania strategicznego

@gswidwa1 / @Michalk001 pytanie dotyczyło sensu dodatkowych zabezpieczeń a nie konkretnych rozwiązań, ale dzięki.

@ZrobieDobrze dzięki za wypowiedź. Faktycznie, pytanie bardziej dotyczyło baz danych, ale chodziło o ustalenie praktyczności dodatkowego zabezpieczenia API np. przed jakimś wyciekiem danych (nieupoważnionym dostępem do bazy do której user nie ma dostępu) - dlatego ostatecznie umieściłem je w dziale dla C# w którym tworzę API.

Czyli tak reasumując: według Ciebie nie ma sensu robić userów na poziomie samej bazy danych - każdy loguje się do bazy na tym samym loginie a API kontroluje z której bazy mają być pobrane dane?

Nie wiem czy to ma znaczenie, ale też taka drobna uwaga: connectionstring-i będą i tak robione w "locie" (z uwagi na konieczność ustawienia właściwej nazwy bazy danych) - liczba baz danych jest nieokreślona (tak w uproszczeniu każdy user może utworzyć nową bazę danych). Dlatego czy w connectionstring-u będzie ten sam user czy różni to nie powinno mieć większego znaczenia (kwestia lekkiej modyfikacji CS-a).

Kofcio napisał(a):

Czyli tak reasumując: według Ciebie nie ma sensu robić userów na poziomie samej bazy danych - każdy loguje się do bazy na tym samym loginie a API kontroluje z której bazy mają być pobrane dane?

Ja jestem przyzwyczajony do jednego wspólnego loginu do bazy (góra dwa - szerszy do upgradu bazy z alter / delete table, niższy do codziennej eksploatacji)
Nie rozumiem - mam wrażenie że skaczesz do rożnych koncepcji multitenancy, od wajchy do wajchy, w tym pytaniu brzmi jak jedna baza dla wszystkich tennantów

Nie wiem czy to ma znaczenie, ale też taka drobna uwaga: connectionstring-i będą i tak robione w "locie" (z uwagi na konieczność ustawienia właściwej nazwy bazy danych) - liczba baz danych jest nieokreślona (tak w uproszczeniu każdy user może utworzyć nową bazę danych). Dlatego czy w connectionstring-u będzie ten sam user czy różni to nie powinno mieć większego znaczenia (kwestia lekkiej modyfikacji CS-a).

Nie wiem co zamierzasz, ale (w nawet nie genialnym, ale) przyzwoitym projekcie obiektowym problem connection stringu jest marginalny, załatwia się sam z siebie

Zadeklaruj, w jakim stylu chcesz to robić, bo jako żywo zestaw pytań pachnie jak jakaś surówka bez warstw / repozytoriów / DAO / whateever

ZrobieDobrze napisał(a):

Nie wiem co zamierzasz, ale (w nawet nie genialnym, ale) przyzwoitym projekcie obiektowym problem connection stringu jest marginalny, załatwia się sam z siebie

ale tutaj connection string jest częścią logiki biznesowej... - dopiero po tym jak user się zaloguje do aplikacji wiadomo z której bazy ma brać dane

abrakadaber napisał(a):

ZrobieDobrze napisał(a):

Nie wiem co zamierzasz, ale (w nawet nie genialnym, ale) przyzwoitym projekcie obiektowym problem connection stringu jest marginalny, załatwia się sam z siebie

ale tutaj connection string jest częścią logiki biznesowej... - dopiero po tym jak user się zaloguje do aplikacji wiadomo z której bazy ma brać dane

oczywiście tak. A to jakiś wielki problem? I tak jakąś sesję czy coś odpowiedniego trzeba trzymać. Tylko producenta connstringa tzreba dostosować, zaprzyjaźniając się z logiką (o ile ta istnieje, bo tu mam mocne negatywne przypuszczenia)

@ZrobieDobrze nie mam dużego doświadczenia w programowaniu, ale mam pewien cel do zrealizowania i sukcesywnie do niego dążę :).

Projekt, który chcę zrealizować został opisany m.in. w tych wątkach:
Jedna duża baza danych vs wiele małych baz danych - wydajność
PostgreSQL vs MySQL - jakie są wasze doświadczenia

W dużym skrócie: piszę prostą aplikację księgową (wystawianie faktur, magazyn, kadry itp.). Dodatkowo celem jest połączenie się z bazą danych programów księgowych z których korzysta biuro rachunkowe - w celu udostępnienia danych swoim klientom (taki pulpit managera).

Co do samej logiki:
Informacje o użytkownikach, nazwach pozostałych baz danych (dla każdej firmy), dostępach, zakazach itd. przetrzymuję w niezależnej bazie danych. Docelowo będzie to prawdopodobnie na niezależnym serwerze.

1. User loguje się na stronie (podaje login + hasło) - jeśli jest OK otrzymuje JWT
2. W JWT jest przechowywana informacja m.in. o bazie danych firmy do której user jest aktualnie zalogowany. Jeśli user ma dostęp do większej liczby baz to może ją zmienić - wówczas aktualizuje się JWT.
3. W JWT przechowywana jest również informacja do których modułów user ma dostęp oraz czy nie ma jakiś ograniczeń.
4. Po wejściu na stronę wymagającą autoryzacji aplikacja wysyła JWT do API -> API odczytuje nazwę bazy danych z JWT -> skleja connectionstringa -> pobiera dane z DB -> przesyła je do usera.

Nie wiem czy coś wymaga uszczegółowienia?
Pytanie w wątku było takie: czy jest sens dodatkowo się zabezpieczyć na poziomie samej bazy danych tworząc loginy dla każdego usera na poziomie bazy danych i dając im analogiczne dostępy.

Kofcio napisał(a):

Projekt, który chcę zrealizować został opisany m.in. w tych wątkach:
Jedna duża baza danych vs wiele małych baz danych - wydajność
PostgreSQL vs MySQL - jakie są wasze doświadczenia

Widzisz .... to są rozważania implementacyjne, a nie opisany "projekt" jak ja rozumiem to słowo (czynnośc a) twórzcza b) zorganizowana, posiadająca plan przed realizacją, w informatyce tzw architekturę.)

BTW dzielne rozwiązujesz problemy przez siebie spowodowane (problemy z bazą, bo patrzysz wyłącznie bazą - patrząc przez abstrakcje byś miał elastyczność decyzji)

Kofcio napisał(a):

Informacje o użytkownikach, nazwach pozostałych baz danych (dla każdej firmy), dostępach, zakazach itd. przetrzymuję w niezależnej bazie danych. Docelowo będzie to prawdopodobnie na niezależnym serwerze.

Czyli w aplikacji użytkowej pojawia się nowa czynność, której wcześnie nie było, do której chcesz zarządzać uprawnieniami ... zmuszasz się do developmentu i utrzymania W DWÓCH miejscach.

Zarządca / właściciel bazy jednej firmy (dobra idea) jednak musi być uprawniony na wysokim stopniu do "bazy wspólnej" .... i całe wysokie wymogi jak bronic wszystkich przed wszystkimi (wytłuściłem) pokazują, jak są fikcyjne.
Bazy (i obsługujące je aplikacje) są dwustronnie od siebie zależne, najgorsza możliwa wersja.
Nie przemyślałeś autentykacja tu i taka, autoryzacja tu i taka.

Mrzonka o dodatkowym serwerze ma ci polepszyć nastrój ?

1. User loguje się na stronie (podaje login + hasło) - jeśli jest OK otrzymuje JWT
2. W JWT jest przechowywana informacja m.in. o bazie danych firmy do której user jest aktualnie zalogowany. Jeśli user ma dostęp do większej liczby baz to może ją zmienić - wówczas aktualizuje się JWT.
3. W JWT przechowywana jest również informacja do których modułów user ma dostęp oraz czy nie ma jakiś ograniczeń.
4. Po wejściu na stronę wymagającą autoryzacji aplikacja wysyła JWT do API -> API odczytuje nazwę bazy danych z JWT -> skleja connectionstringa -> pobiera dane z DB -> przesyła je do usera.

Nie wiem czy coś wymaga uszczegółowienia?
Pytanie w wątku było takie: czy jest sens dodatkowo się zabezpieczyć na poziomie samej bazy danych tworząc loginy dla każdego usera na poziomie bazy danych i dając im analogiczne dostępy.

Pozór technologii cloudowej jest (wg mnie) zasłoną dymną przed samym sobą. To nawet nie jest rozproszony monolit, tylko rozproszony beton-monilit

Kofcio napisał(a):

W dużym skrócie: piszę prostą aplikację księgową (wystawianie faktur, magazyn, kadry itp.).

"Polski Erp nr 2374"
Podaj nazwę, chciałbym wiedzieć (jakby któremuś ze znajomych świtało to kupić)

@ZrobieDobrze Nierozumiem po co te wyśmiewanie się. Ja nie robię tego w celach komercyjnych, tylko żeby się czegoś nauczyć i żeby mieć coś swojego. Robię to czysto hobbystycznie. Nie jestem z zawodu programistą i wielu rzeczy nie wiem, dlatego zadaję pytania na forum. Nie każde moje rozwiązanie jest właściwe, ale nie mam tego komfortu, żeby to omówić z kimś mądrzejszym.

Na reddicie też był gość co szukał repozytorium na Git'cie, z przykładem systemu ERP, bo też dla nauki chciał sobie napisać swoje... Póki nie spróbujesz gotowego ERPa jak Enova, Optima, Subiekt, Wapro i nie zajrzysz co dzieje się pod maską, to nie zrozumiesz złożoności takich projektów. Wrzucasz się na głęboką wodę myśląc, że wystawianie faktur, magazyn, kadry itp. to zwykły insert do bazy.

Nie jestem z zawodu programistą i wielu rzeczy nie wiem, dlatego zadaję pytania na forum. Nie każde moje rozwiązanie jest właściwe, ale nie mam tego komfortu, żeby to omówić z kimś mądrzejszym.

Rozmawiasz tutaj z mądrzejszymi właśnie. To co ci koledzy sugerują to właśnie jest rozwiązanie twojego problemu, który jest wierzchołkiem góry lodowej. Póki nie nadrobisz braków mniejszymi projektami, nie zrozumiesz, że ktoś ci bardzo dobrze podpowiada.

PS.
Zrobiłbym to jedną bazą i ograniczył na poziomie IdFirma oraz IdUser. A jeśli chodzi o dodatkowe zabezpieczenia to przypominam, że projekt jest do nauki, nikt nie będzie ci twojego ERPa "hakował", oprócz ciebie. Szczerze mówiąc to nawet nie dojdziesz do zabezpieczeń, bo pokonają cię kartoteki towarów i kontrahentów, a o fakturach nawet nie wspominam... ✌ Good luck ✌

Kofcio napisał(a):

@ZrobieDobrze Nierozumiem po co te wyśmiewanie się. Ja nie robię tego w celach komercyjnych, tylko żeby się czegoś nauczyć i żeby mieć coś swojego.

To ciekawe, w wątku który sam wskazałeś, planujesz wzrost z kilkudziesięciu do tysiąca klientów. To tak dla przypomnienia.

Kofcio napisał(a):

Robię to czysto hobbystycznie. Nie jestem z zawodu programistą i wielu rzeczy nie wiem, dlatego zadaję pytania na forum. Nie każde moje rozwiązanie jest właściwe, ale nie mam tego komfortu, żeby to omówić z kimś mądrzejszym.

Postaw kawę nauczycielowi gitary, albo trenerowi pływania, zapytaj "lepiej się uczuć źle, czy wcale ?"

Co się nauczyłeś z C#, który jest b. dobrym jezykiem, i z projektowania i programowania obiektowego ?

"My" (w sensie jaki użył @AdamWox ) mieliśmy takie fale samouków, samotnych fighterów (we własnej opinii), którzy liznęli design wizualny w Delphi, zobaczyli przez ramię PHP v.3, zobaczyli perspektywę trzepania kasy w Excellu itd, zabetonowanych w skali wieloletniej na dostzreżenie czegoś innego niż własne metody, własne nawyki, odpornych na profesjonalne ksiazki - i przekonanych o własnej doskonałosci

AdamWox napisał(a):

Na reddicie też był gość co szukał repozytorium na Git'cie, z przykładem systemu ERP, bo też dla nauki chciał sobie napisać swoje... Póki nie spróbujesz gotowego ERPa jak Enova, Optima, Subiekt, Wapro i nie zajrzysz co dzieje się pod maską, to nie zrozumiesz złożoności takich projektów. Wrzucasz się na głęboką wodę myśląc, że wystawianie faktur, magazyn, kadry itp. to zwykły insert do bazy.

Znam niejeden taki program - również od strony bazy danych.

AdamWox napisał(a):

Rozmawiasz tutaj z mądrzejszymi właśnie. To co ci koledzy sugerują to właśnie jest rozwiązanie twojego problemu, który jest wierzchołkiem góry lodowej. Póki nie nadrobisz braków mniejszymi projektami, nie zrozumiesz, że ktoś ci bardzo dobrze podpowiada.

Problem jest w tym, że koledzy nic mi nie sugerują - dyskusja zamiast skoncentrować się na pytaniu przesunęła się w kierunku "to bez sensu, to za trudne, zrezygnuj".

AdamWox napisał(a):

PS.
Zrobiłbym to jedną bazą i ograniczył na poziomie IdFirma oraz IdUser. A jeśli chodzi o dodatkowe zabezpieczenia to przypominam, że projekt jest do nauki, nikt nie będzie ci twojego ERPa "hakował", oprócz ciebie. Szczerze mówiąc to nawet nie dojdziesz do zabezpieczeń, bo pokonają cię kartoteki towarów i kontrahentów, a o fakturach nawet nie wspominam... ✌ Good luck ✌

Pytanie o to czy zastosować jedną bazę czy wiele było w innym wątku i już postanowiłem, że będzie wiele - tak jak praktycznie każdym większym ERP, ale dzięki za sugestie.

ZrobieDobrze napisał(a):

Kofcio napisał(a):

@ZrobieDobrze Nierozumiem po co te wyśmiewanie się. Ja nie robię tego w celach komercyjnych, tylko żeby się czegoś nauczyć i żeby mieć coś swojego.

To ciekawe, w wątku który sam wskazałeś, planujesz wzrost z kilkudziesięciu do tysiąca klientów. To tak dla przypomnienia.

Po pierwsze ta informacja było z przymrużeniem oka. Po drugie nie klientów tylko użytkowników - użytkownikiem może być np. pracownik firmy.

ZrobieDobrze napisał(a):

Kofcio napisał(a):

@ZrobieDobrze Nierozumiem po co te wyśmiewanie się. Ja nie robię tego w celach komercyjnych, tylko żeby się czegoś nauczyć i żeby mieć coś swojego.
Postaw kawę nauczycielowi gitary, albo trenerowi pływania, zapytaj "lepiej się uczuć źle, czy wcale ?"

Nie rozumiem Twoich odpowiedzi. Przecież ja się cały czas uczę... To że zadaję pytanie na forum to coś w tym złego?!

ZrobieDobrze napisał(a):

"My" (w sensie jaki użył @AdamWox ) mieliśmy takie fale samouków, samotnych fighterów (we własnej opinii), którzy liznęli design wizualny w Delphi, zobaczyli przez ramię PHP v.3, zobaczyli perspektywę trzepania kasy w Excellu itd, zabetonowanych w skali wieloletniej na dostzreżenie czegoś innego niż własne metody, własne nawyki, odpornych na profesjonalne ksiazki - i przekonanych o własnej doskonałosci

Gratuluję, ale co z tego?

Kofcio napisał(a):

abrakadaber napisał(a):

Jak dla mnie to w przypadku kiedy jeden user może mieć dostęp do wielu firm (w rzeczywistości do wielu baz), cały pomysł aby każda firma miała osobną bazę jest mocno na wyrost, nie mówiąc już o tym aby każdy user łączył się z bazą na własnym haśle. Przecież nie będziesz dawał userom dostępu wprost do bazy a przez twoje oprogramowanie.

Bazy muszą być osobno dla każdej firmy - z tego się już nie wycofam z uwagi na zbyt dużą liczbę danych wrażliwych (dane osobowe etc.).
User w danej chwili może mieć dostęp tylko do jednej bazy danych (jak ma dostęp do większej liczby baz to może się przełączyć, ale w danej chwili dostęp jest tylko do jednej z nich).
Hasło użytkownika może być takie samo dla wszystkich userów - nie będzie dostępne publicznie.

@Kofcio: Skoro uważasz że jest "za późno" to pewnie z tej rady nie skorzystasz, ale wydaje
mi się że ... cóż ... pisałeś że to nie jest serwis komercyjny i że po prostu robisz sobie coś takiego na zasadzie "żeby zrobić i żeby się czegoś nauczyć".
Moim zdaniem nie ma nic złego w tym, abyś "niestety" zrobił ten serwis jeszcze raz od zera. Tylko wcześniej musiałbyś przez jakiegoś client'a po
prostu pobrać te wrażliwe dane a potem je "jakoś" zapisał w drugiej wersji projektu. Natomiast po co od zera? Ja na twoim miejscu
zaprojektowałbym całą "jedną" bazę danych od początku i przed migracjami porządnie przeprowadził jej normalizację usuwając strukturalne błędy.
I to nawet można by to zrobić w jakimś excelu lub calcu. Tu pewnie wielu mnie wyśmieje, ale osobiście uważam że to jest dobre
rozwiązanie żeby przyzwyczaić umysł do myślenia oraz wychwytywania swoich własnych błędów. Bo zaprojektujesz w zwykłym calcu taką
rozległą bazę danych i sam zobaczysz ile rzeczy wtedy sobie utrwalisz... skoro to jeszcze nauka. Chociaż spoko, ja też się cały czas uczę.

Poza tym czemu nie miałbyś zamiast 100 oddzielnych baz danych zrobić po prostu jedną tabelę "UsersDatabases" w jednej fizycznej bazie???
Bo @abrakadaber ma chyba rację że robienie 100 oddzielnych baz danych jest trochę bez sensu.
Plusy:
Miałbyś wszystko w jednym miejscu i prawdopodobnie nie miałbyś takich problemów jak ten, który masz teraz.
Jeśli to nie jest apka komercyjna, to robiąc ją od zera utrwaliłbyś swoją wiedzę, tudzież nauczyłbyś się czegoś
Minusy:
No na pewno straciłbyś dużo czasu, ale niestety w programowaniu jest jak w dziennikarstwie. Jeśli chcesz w tym robić i
jeśli chcesz się czegoś nauczyć, to nie masz co marzyć o życiu towarzyskim i innych takich. Niestety;-)) Po prostu siedzisz
i kodujesz. I to czasami niestety do późna w nocy.

edit: @Kofcio Właściwie chciałbym dodać jeszcze jedno. Powiem tak, że ja się już przyzwyczaiłem do tego, że jak wrzucam nowy wątek, to nagle
pojawia się 100 hejtujących i wyśmiewających Ciebie postów, które do niczego nie prowadzą a służą jedynie "dość nieskutecznej" autoreklamie niektórych programistów. Nieskutecznej, bo jak kogoś takiego "zgłosisz" że poza hejtowaniem niczego nowego taka osoba nie wnosi do wątku, to taki "wielki doświadczony" programista dostaje bana ... ;-)) ... i tyle wynika z jego autoreklamy;-)) Natomiast według mnie od bardzo dawna istnieje na ziemi taki bardzo bardzo fajny język programowania, nazywa się "samokrytyka++". I niestety jest wielu takich programistów którzy siedzą od 15 lat w C#,PHP, Java czy w innym języku, jednak jeśli zapytasz czy znają "samokrytykę++" to prędko się przekonasz że "niestety w tej dziedzinie kompetencji brak";-))) Ale spoko. Ja już po prostu mam dystans. Jak trochę po kodujesz to się przyzwyczaisz;-))