[HomeWallet] Baza Danych

Cześć!

Daj się poznać startuje na dobre, czas więc na coś technicznego 🙂 Tak jak obiecałem w poprzednim wpisie, dzisiaj o bazie danych.

HomeWallet będzie pisany w .NET Core, głównie przez multiplatformowość. Dzięki temu będę w stanie pisać zarówno na Windowsie jak i na macOS. Aby jeszcze bardziej ułatwić cały proces, postanowiłem postawić bazę danych w chmurze. Dzięki temu nie ma żadnego problemu, że jakaś baza działa na jednym systemie a na drugim nie. Dodatkowo baza w chmurze daje otwarte pole do pisania WebAPI które kiedyś może powstanie.


DigitalOcean

Jako student mam dostęp do GitHub Student Developer Pack. Z paczki tej dostajemy m.in. 50$ na rok w serwisie DigitalOcean. Pozwala to na wykupienie serwera na 10 miesięcy, co jak na razie mi w zupełności wystarczy. Nie jest to nic specjalnego, ale pod samą bazę jest to więcej niż wystarczająco 🙂

Tworzenie dropletu w DigitalOcean

 

Sam proces jest banalnie prosty. Wybieramy system, w moim wypadku Ubuntu, plan cenowy, lokalizację i już jesteśmy w stanie stworzyć swój droplet. Następnie na Ubuntu instalujemy bazę i gotowe. Jest też możliwość wybrania „One-click apps”, nie ma tam jednak PostgreSQL.

Instalacja PostgreSQL

 

Aby PostgreSQL był otwarty na świat zewnętrzny, należy jeszcze edytować dwa pliki:

Najpierw zmieniamy plik postgresql.conf i ustawiamy jakie IP mają być „słuchane”. „*” oznacza wszystkie IP.

Edycja pliku postgresql.conf

Następnie zmieniamy plik pg_hba.conf i ustawiamy akceptowanie przychodzących połączeń

Edycja pliku pg_hba.conf

Na samym końcu restartujemy bazę:

Restart PostgreSQL

 


PostgreSQL

 

Dlaczego PostgreSQL? Bo działa. I wiem, że nie będę miał z nią aż tyle problemów, co z MySQL. Doświadczenia z bazami praktycznie nie mam. Moje wymagania spełniają wszystkie bazy na rynku. Wiem jednak, że z MySQL miałem w przeszłości problemy z konfiguracją, podczas gdy z PostgreSQL ich nie było. Oczywiście przy .NET od razu myśli się o MS SQL Server, ale wersja na Linuxa jest dopiero w preview. Ot i cała filozofia wybrania bazy 😉


Schemat

 

Na studiach nauczyłem się, że przed rozpoczęciem pisania aplikacji warto wziąć mazak w rękę i rozrysować sobie bazę. Dzięki temu jesteśmy w stanie zobaczyć jakie problemy mogą się pojawić jak i lepiej przemyśleć ogólny zarys aplikacji.

Wstępny schemat na tablicy

Mój schemat ostatecznie prezentuje się następująco:

Schemat Bazy Danych

 

Jak widać, zamysł nie jest skomplikowany. Mamy paragon, który posiada listę produktów. Produkty mają swoje kategorie. Paragon jest przypisany do konkretnego sklepu oraz użytkownika. Można dodać paragon cykliczny, który ma swoją datę początkową i końcową oraz cykl liczony prawdopodobnie w dniach. Dodatkowo użytkownik może planować wydatki. Tabela dla użytkownika jest tu bardzo uproszczona, gdyż będę korzystał z gotowego rozwiązania od Microsoftu do autoryzacji użytkowników.

Na pewno nie jest to ostateczny schemat. Na pewno zmieni się wiele razy. Pozwala on jednak trzymać się jakiejś ogólnej wizji.


Następnym krokiem będzie już przeniesienie schematu na kod. To jednak już w następnym wpisie, który jeszcze w tym tygodniu 🙂

 

Dziękuję również za cały feedback do poprzedniego wpisu. Fajnie wiedzieć, że ktoś to czyta i kogoś to interesuje. Do zobaczenia niedługo!

 

2 komentarzy

  1. Wypadałoby przewidzieć, że cena produktu się zmienia, ale zmiana ceny nie powoduje zmiany na paragonie i skąd ta cena ma być w danym momencie pobrana. W tym momencie Product nie posiada ceny stąd też nie ma skąd ona być wzięta do tabeli Receipt_Product. Ja proponowałbym, żeby zrobić to w ten sposób, że paragon ma pozycje, pozycje mają powiązanie z produktem, zaś cenę posiada zarówno produkt (aktualna cena) oraz pozycja paragonu (cena na paragonie). Takie podejście pozwoli zarówno na zmianę cenówek jak i dawanie rabatów na produkty. Dodatkowo warto by zastanowić się nad dodaniem tabeli/kolumny ilość do produktów 😉 Do tego skoro wszystkie Id mają typ int to Id użytkownika też wypadałoby, żeby miało Id liczbowy, jeśli spowodowane jest tym, że użytkownik ma jakiś kod to warto jednak byłoby go zapisać w dodatkowej kolumnie. Co do samego schematu, polecam jednak stosować schematy w których mamy informacje o tym jakiego typu powiązania mamy między tabelami np. IDEFIX. Pozdrawiam

    1. juniornetdev says: Odpowiedz

      Cena produktu będzie pobierana od użytkownika, sam produkt nie będzie miał na stałe przypisanej ceny, bo IMHO nie ma to sensu, bo ten sam produkt z różnych sklepów jednak ma zazwyczaj inną cenę, a nie chcę, aby produkt w bazie był produktem z danego sklepu, a jedynie pozycją uniwersalną. Pojawia się jedynie kwestia może jakiegoś autouzupełniania aby nie zrazić wpisywaniem za każdym razem ceny, ale to jest na razie drugorzędna sprawa. Ilość również znajduje się w tabeli łączącej, która odpowiada właśnie za „pozycję” z Twojego pomysłu. Wydaje mi się, że po prostu mamy nieco inną wizję na to, czym jest produkt w tej bazie i stąd różnice w myśleniu.
      Co do użytkownika, to jest to spowodowane tym, że EF tworzy klucz dla użytkownika w postaci tekstowej. Czy tak się powinno robić czy nie trudno mi stwierdzić, bo bazowcem nie jestem, poczytam jednak o tym 🙂
      Na schemacie faktycznie brakuje typów powiązań, mój błąd, zupełnie o tym zapomniałem.
      Dzięki za komentarz, fajnie, że ktoś analizuje to co robię 🙂

Dodaj komentarz