Cisza na blogu w ostatnich dniach spowodowana była pracą nad innym projektem. Nie jest one jeszcze skończony, zatem przez najbliższe 2-3 tygodnie prace nad LogTree dość znacznie zwolnią. Mam jednak nadzieję, że zdołam pisać dwa posty tygodniowo o postępach nad pracami.
Ostatnio problemem któremu poświęcam najwięcej uwagi jest sposób przechowywania danych. W grę wchodzą dwie możliwości. Pierwsza z nich opiera się na wskaźnikach, druga na indeksach. Każda z nich ma swoje wady i zalety, które postaram się pokrótce przedstawić.
Jak już powiedziałem, pierwsza opcja opiera się na wskaźnikach. Odpowiedzialną za obsługę tego rozwiązania jest klasa db::TreeVertex, która oprócz danych dotyczących posta, takich jak tytuł, treść czy data, przechowuje wskaźniki na powiązane z nią posty - przodka, następny post w linii i odgałęzienia. Niewątpliwym plusem tej opcji jest jej samowystarczalność, jeżeli chodzi o większość funkcji jakie powinna posiadać baza danych. Wystarczy tylko ta jedna klasa oraz wskaźnik na jej instancję, odpowiedzialną za obecnie przetwarzany element, aby móc swobodnie nawigować po całym drzewie, wyświetlać i modyfikować wszystkie posty. Dodatkowa klasa może być potrzebna dopiero do obsługi tagów. System ten ma jednak bardzo istotną wadę: zapisanie bazy do pliku wymaga jej spłaszczenia - zapisania w tablicy bądź vectorze. Dodatkowo zapis pojedynczego postu, o ile jest możliwy, byłby zdecydowanie utrudniony: nie wiadomo gdzie w pliku zaczyna się i kończy który wpis.
Problem ten rozwiązuje druga możliwość przechowywania danych: vector obiektów typu db::Entry, który nie przechowuje wskaźników na posty powiązane, a jedynie ich indeksy we wspomnianej strukturze. Dzięki temu, że posty przechowywane są w linii, płasko, można je wygodnie zapisywać do pliku, nawet pojedynczo. Zachowuje przy tym możliwość łatwej nawigacji po drzewie i modyfikacji pojedynczych postów, chociaż potrzebna jest do tego dodatkowa klasa db::Base. Nie jest to jednak rozwiązanie idealne, ma jedną bardzo istotną wadę: usunięcie wpisu powoduje fragmentację danych. Można co prawda do powstałej luki przesunąć post z końca tablicy, jednak zdecydowanie spowalnia to usuwanie wpisów, szczególnie jeżeli jednocześnie chcemy pozbyć się wszystkich jego odgałęzień i następców.
Decyzja o wyborze jednej z opcji nie jest prosta. Postanowiłem rozwijać obie wersje i poddawać je testom wydajnościowym po dodaniu każdej nowej funkcjonalności. Będzie to wymagać większych nakładów czasu, jednak mam nadzieję, że dzięki temu uda mi się stworzyć system bazy danych, który będzie wydajny i nie będzie sprawiał problemów przy dalszym rozwijaniu projektu.
Brak komentarzy:
Prześlij komentarz