Raczej nie sprzedawałbyś programu który w wyniku awarii zasilania traci dane wprowadzone od ostatniego uruchomienia...
Aha, czyli według Ciebie wszystkie programy, które korzystają z DOMu są bezwartościowe? Bo przecież zbudowanie modelu dokumentu w pamięci wiąże się z załadowaniem całego pliku/strumienia, dzięki czemu operuje się cały czas na pamięci RAM;
Pamętaj, że bazy danych to jedno, a konfiguracje to drugie; Bazy nie ładuje się w całości do pamięci, bo to sensu nie ma; Poza tym takie bazy mogą zajmować dużo więcej przestrzeni niż cała dostępna dla procesu pamięć, dlatego takie rozwiązanie było by bezwartościowe; Natomiast nic nie stoi na przeszkodzie, aby konfigurację ładować w całości, bo to zwykle nieduże pliki, a rodzaj danych nie jest tak ważny jak w przypadku danych w bazach; Poza tym model dokumentu można w dowolnej chwili zapisać do pliku, kiedy tylko będzie to konieczne, więc w momencie awarii albo mamy zapisaną zawartość nowego modelu, albo mamy plik z poprzednią konfiguracją;
Przykładem jest konfiguracja aplikacji desktopowej czy gry - w pamięci znajduje się załadowana w całości konfiguracja, użytkownik/gracz wchodzi w ustawienia i zmienia co mu potrzeba; Wybiera opcję Save, co powoduje zaktualizowanie danych w modelu, a on sam zapisywany jest do pliku; Nic w tym dziwnego, bo plik zostaje zaktualizowany tylko raz; Gdyby klasa obsługująca model wykonywała aktualizację po każdej zmianie zawartości modelu, to plik byłby aktualizowany wiele razy, a potrzebny byłby tylko ten jeden raz;
Oczywiście i te pierwsze moim zdaniem są o wiele lepsze.
W tym rzecz że ani jedno, ani drugie, a raczej i jego i drugie;
Wszystko zależy od przypadku - m.in. od przeznaczenia zbioru danych, typu przechowywanych informacji i ich ważności; Nie można jednoznacznie wskazać lepszego rozwiązania, bo dla ogółu taki nie istnieje;
Pisane było za pomocą standardowego komponentu TIniFile z C++ Buildera i niestety zapisywanie wszystkiego co 1s (bo w takich okresach odświeżałem dane) spowodowało że malutki program w statystykach IO był na jednym z pierwszych miejsc pod względem zapisanych/odczytanych bajtów.
No i sam widzisz, że aktualizowanie pliku co sekundę jest złym rozwiązaniem; Mogłeś skorzystać z klasy TMemIniFile i operować tylko i wyłącznie na danych na stercie (głównie albo tylko i wyłącznie na RAM) i nie mieliłbyś dyskiem; Jeśli co sekundę używałeś jakiejkolwiek metody zapisującej dane w jakimś kluczu, np. WriteString, to za każdym razem aktualizowałeś cały plik, bo tak właście działa klasa której użyłeś; TMemIniFile wszystko keszuje i daje możliwość wybrania momentu, w którym model zostanie zserializowany do pliku;
A właśnie zamiast csv niech nasz pytacz rozpracuje pliki dbf?
Pytacz chyba się przestraszył, ale może niech lepiej sam wybierze, żeby potrafił z tego skorzystać.