Punkt drugi listy wypunktowanej w poprzednim wpisie głosi: projektowanie bazy danych. Jest to dość kłopotliwy problem, który można rozwiązać na wiele sposobów. Kłopotliwość polega na wybraniu rozwiązania najlepiej dostosowanego do wymagań projektowych. Wiadomo, że każdy błąd popełniony podczas projektowania mści się tym bardziej, im później zostanie wykryty i im więcej warstw aplikacji opiera się na błędnym module. Na bazie, jak to na bazie, opiera się właściwie wszystko – dlatego błędy na tym etapie są szczególnie niemile widziane.
Do dzieła. Przypomnę wymagania dotyczące tego etapu: „chcę nadawać wydatkom kategorie”, „chcę móc zdefiniować wydatki stałe”. Dosyć oczywiste wydają się więc tabele bazy danych: kategorie wydatków, wydatki jednorazowe, wydatki stałe – i ich przyjemniejsze odpowiedniki: kategorie przychodów, przychody jednorazowe, przychody stałe.
Kategorie nie powinny sprawić problemu – niech zawierają, oprócz identyfikatora, tylko nazwę.
Wydatki (przychody) jednorazowe niech cechuje ich wartość, kategoria, nazwa (warto odróżnić kategorię od nazwy: w kategorii „alkohol” może znajdować się np. wydatek o nazwie “komandos z braciszkiem”), data, flaga oczekujący / zapłacony (otrzymany) i notatki (np. n-ta z kolei notatka: „zapamiętać: nigdy więcej komandosa”).
Wydatki (przychody) stałe wymagają, jak wspomniałem dwie notki niżej, zastanowienia. Pierwsza moja myśl: mogłyby mieć przypisany okres czasu (np. czynsz za akademik: październik 2009 – czerwiec 2010). Przy rozliczaniu jakiegoś okresu (np. pierwszy kwartał 2010) wyliczałbym mnożnik danego wydatku (w danym przykładzie: 3, bo rozliczam 3 miesiące) i obliczał kwotę, o którą wydatek ten uszczuplił portfel użytkownika. Nieco niewygodne, ale oszczędne – każdy wydatek to tylko jeden wiersz w tabeli bazy. Wtem! Druga moja myśl: akcja „weryfikuj wydatki stałe”, o której mowa w wymaganiach, wymaga, aby dany wydatek stały każdego miesiąca osobno mógł być oznaczony jako zapłacony. Okresowość wydatków może być realizowana przez dodanie ich tylu, ilu miesięcy dotyczą (po jednym wydatku na miesiąc). Decyduję się więc na rozwiązanie najprostsze: wydatki (przychody) stałe mają identyczną strukturę z jednorazowymi. W polu „data” dni nie mają znaczenia – wydatek (przychód) dotyczy całego miesiąca.
Podsumowując, baza danych zawiera sześć tabel:
– ExpenseCategories / IncomeCategories o polach:
1) Id [int]
2) Name [nvarchar]
– Expenses / ConstantExpenses / Incomes / ConstantIncomes o jednolitej strukturze pól:
1) Id [int]
2) ExpenseCategoryId / IncomeCategoryId [int]
3) Name [nvarchar]
4) Value [money]
5) Date [datetime]
6) Paid / Gained [bit]
7) Notes [nvarchar]