Tworzenie plików archiwalnych

0

Cześć Wam,
Mam pytanie nie tyle dotyczące samego języka ale problemu logicznego — algorytmicznego.
Mam program zapisujący różnego rodzaju grafiki pracy - stanowiska itp dane i na podstawie tego wyświetla tabele obsady stanowisk, schematy grafików mogą być modyfikowane z poziomu samego programu i zaawansowanych w dostępie użytkowników.
Problem pojawia się gdy zapisane schematy grafików lub innych struktur danych ulegną zmianie w czasie. Wówczas nie można odtworzyć np dyżurów z przed zmiany ich struktury. Np z przed 5 lat. A mogą to być dane potrzebne nie mogą to być też dane wprost zapisane w tabele bo na podstawie innych schematów obliczane są dane pochodne.
Kłopot w tym że zmiany schematu ich zapisu są już inne po czasie (bo ktoś je zmienił- np stanowisko zniknęło lub jest inne)i program nie może prawidłowo (bez np dziur) przedstawić kto pracował w wigilie 4 lata temu i co robił na jakim stanowisku pracy.
Żeby ten problem w przyszłości ominąć przyszedł mi do głowy pomysł tworzenia plików archiwalnych schematów grafików pracy.
Wszystkie schematy wszystkich grafików znajdują się w jednym ttreeview w pliku txt.
I sposób miałby wyglądać tak , że przy każdej zmianie tego pliku tworzony byłby plik archiwalny O nazwie arch_data-data.txt Gdzie data-data to zakres czasu gdy dany schemat obowiązywał.
Wtedy program zawsze mógłby sprawdzić jak wyglądał schemat i prawidłowo odczytać tabele obsady stanowisk pracy, czasów itd.
Czy pomysł ten wydaje się wam sensowny?
Programuję od dawna ale hobbistycznie, dlatego może wyważam otwarte drzwi. wydaje mi się jednak to dość proste do osiągnięcia. Co myślicie?

Jeśli program nie będzie miał możliwości powrotu do starej wersji wyglądu I organizacji poszczególnych grafików stanie się mało funkcjonalny dla szeregowego pracownika.
Poza tym program nie odnajdzie Np w umowach poszczególnych osób z danego okresu np ich stawek i nie będzie można łatwo obliczyć wynagrodzeń za prace np jakie było 4-5 lat temu. Nie zrobi tego gdyż w tabeli grafiku całościowego będą mogły być prawidłowo zinterpretowane dane odnoszące się do obecnego grafiku a nie z przed x lat.
Program ma być jak najmniej zamknięty w schematach gromadzenia danych bo te ulegają dość dużym zmianom(schematy).
Obecnie mój stary program(Działa od 7 lat) jest niestety mało otwarty i każda zmiana schematu powoduje brak możliwości poprawnych obliczeń części danych - Pozwala jedynie na wyświetlenie danych które pasują do schematu aktualnego , nie pasujące są pomijane lub ustawiam znak „?” Np w miejscu gdzie ktoś przepracował X godzin na stanowisku „?”- które już nie istnieje. A np gdy grafik dyżurów się otworzy do edycji ( np z roku 2018) w sytuacji gdy jeden pion wtedy istniał a obecnie nie ,to nie zostanie on wyświetlony bo program nie ma gdzie sprawdzić do jakiego grafiku jest przypisana zapisana w tabeli dana.
Zapisanie w tabeli grafiku całościowego danej w sposób bezwzględny wydaje się również bezużyteczne bo nazwy poszczególnych pionów stanowisk również ulegają zmianie z czasem.

2

Jeszcze ci się chce utrzymywać samoróbny program kadrowy ?
Kto do tego dopłaca, Ty zaniżając efektywną stawkę, czy klient bo musi?

KAŻDY z twoich problemów jest obsłużony w programie profesjonalnym.

  1. Danych się nie kasuje, tylko wyłącza ich aktywność, to elementarz.

  2. Bazy danych dostarczają narzędzi do "historyczności" np Posgres, ale jakby nie chcieć się uzależniać od specyficznych ficzerów, to na każdym serwerze SQL da się ZAPROJEKTOWAĆ bazę, która historyczność ma.

Windowbee napisał(a):

Wszystkie schematy wszystkich grafików znajdują się w jednym ttreeview w pliku txt.

I to jest główny problem ekosystemu Delphi: patrzenie przez komponenty wizualne, a nie przez architekturę, specyfikację, elastyczny model danych itd... i kilka jeszcze słówek w tym ekosystemie nieznanych

1

To program dla mojego oddziału i robię sam bo szpital nie kupi ,a oszczędza nam mnóstwo czasu i pozwala na uniknięcie kłótni(kto ma spedzieć trzysetną godzinę w miesiàcu w pracy w wigilię). Wiec tak dopłacam sam siedząc w dyżurce w czasie wolnym gdy nic się akurat nie dzieje. Dlatego wybacz nieudolność robiłem to hobbystycznie ucząc się lazarusa. Szpital też programu mojego nie wrzuci na serwer dlatego zrobilem obsługę internetową drogą przez ftp. Komputer matkę oczywiście musieliśmy kupić sami i przekazać w darowiźnie szpitalowi żeby miał internet.
Komponenty wizualne są tworzone dynamicznie tak jak prawie 50 form.
Obciążenie procesora 1,3% przy szukaniu danych w pliku 100mb 20%. Pamięć ram 50-70 mb zajmuje.
Kiepsko ale tyle potrafię. A bazy danych nie zalatwią sprawy prawidłowego interpretowania danych archiwalnych- które nie giną ale nie sposób ich zinterpretować gdy stary interpreter gdy byly wprowadzane juz nie istnieje

0

A bazy danych nie zalatwią sprawy prawidłowego interpretowania danych archiwalnych- które nie giną ale nie sposób ich zinterpretować gdy stary interpreter gdy byly wprowadzane juz nie istnieje

albo przynajmniej tak Ci się wydaje w programie amatorskim

Kiepsko ale tyle potrafię.

To nie znaczy, ze innym nie udało się więcej.

Zapewniam Cię, że program, który sprzedaję, da się tak wdrożyć

0

Wierzę, wierzę bo jesteś w tym profesjonalistą. Ja hobbystą i do tego mającym mniej zdecydowanie czasu.
Może w takim razie byłbyś wstanie mi powiedzieć jak w takim razie działają bazy danych z takim problemem jak np ten przykład:
Masz grafik składający się z tabeli 365 dni 2021roku. W każdym dniu wpisani są pracownicy zgodnie ze swoim unikalnym kodem- numerem z innej tabeli użytkowników.
Każdy użytkownik obsadza w tej tabeli 365 dniowej przypisane mu stanowisko - jest ono opisane w tabeli za pomocą atrybutów jak np unikalny numer identyfikacyjny stanowiska oraz czas pracy w ciągu dyżuru w ciągu zwyklego dnia i wiele innych charakterystyk.
Jest też tabela wynagrodzen za czynnosci wykonywane na tym stanowisku.
Wszystko dziala idealnie gdy nie następują zmiany w tabelach opisujących stanowiska. Ale gdy tam wypadnie jakieś stanowisko bo zniknie program musiałby szukać w archiwum opis tego stanowiska- jego atrybuty. I to jest latwo zrobic tworząc plik bin do ktorego wrzucę wyrzucane stanowiska i i ich atrybuty.
Jednak nie pozowoli to na odtworzenie grafiku np pochodnego grafiku głównego zawierającego tylko dyżury a nie prace codzienną. Bo już go nie ma - nie ma tego wzoru dyżurów jest zupełnie inny układ. Dane zostały ale nie można ich prawidłowo - w taki sposób przedstawić jak były widoczne przed zmianą. Trzeba by zapamiętać od kiedy do kiedy obowiązywał dany schemat i jak wyglądał.
Jak z takimi sytuacjami radzi sobie Twoj program?

8
Windowbee napisał(a):

Dlatego wybacz nieudolność robiłem to hobbystycznie ucząc się lazarusa. Szpital też programu mojego nie wrzuci na serwer dlatego zrobilem obsługę internetową drogą przez ftp. Komputer matkę oczywiście musieliśmy kupić sami i przekazać w darowiźnie szpitalowi żeby miał internet.

Chłopie, przestań się tłumaczyć i pisać z pozycji ofiary — umiesz tyle ile umiesz, zrobiłeś tyle ile potrafiłeś i powinieneś być z tego dumny. A przede wszystkim nie powinieneś przepraszać jakichś randomowych trolli, którzy nie widzą różnicy między Delphi a użytkownikiem Delphi i nie umieją nic sensownego napisać prócz „Delphi, fuj, dziadostwo, bez sensu, komponenty, szkoda czasu”. :D

Windowbee napisał(a):

Jak z takimi sytuacjami radzi sobie Twoj program?

Ten wątek dotyczy Twojego programu, nie innych użytkowników czy oprogramowania komercyjnego firm trzecich, więc nie zbaczaj z tematu i nie pozwól robić w wątku off-topu. Ewentualnie off-top ciągnij w komentarzach, bo do tego służą.


Nie wiem czy dobrze rozumiem, ale Twoja baza danych to po prostu pliki tekstowe z danymi w znanym formacie. Problemem natomiast jest to, że jak zmienisz format danych w pliku i zaktualizujesz interpreter, to program przestaje mieć możliwość poprawnego odczytu danych z poprzedniej wersji formatu.

Jeśli tak faktycznie jest, to najłatwiejszym rozwiązaniem jest wpisywanie do pliku numeru wersji formatu. Natomiast interpreter w trakcie aktualizacji powinien być rozbudowywany, bez usuwania funkcjonalności poprzedniej wersji. Podczas analizy pliku tekstowego, sprawdzasz która jest to wersja formatu i wybierasz odpowiedni algorytm interpretera. Dzięki temu nie złamiesz wstecznej kompatybilności.

Co do plików archiwalnych — nie znam architektury Twojego programu, ale jeśli pewne dane są z pliku usuwane w trakcie zmiany „schematu”, to bezpowrotnie tracisz do nich dostęp, stąd jakakolwiek forma kopii/archiwum jest konieczna. No bo trudno odczytać dane, których ani nie ma w pliku, ani nawet nie wiadomo w jakim formacie byłyby hipotetycznie zapisane.

2

Obecnie mój stary program(Działa od 7 lat) jest niestety mało otwarty i każda zmiana schematu powoduje brak możliwości poprawnych obliczeń części danych - Pozwala jedynie na wyświetlenie danych które pasują do schematu aktualnego

A tak swoją drogą, skoro to ma być i tak dość mocna prowizorka, to może razem ze starymi danymi trzymaj starą wersję aplikacji?
Potem, gdy powstaje nowa wersja/wprowadzasz zmiany w grafiku, to tworzysz nową wersję EXE, poprzednie dane archiwizujesz (całość - dane i aplikację) i zaczynasz pracę na nowo. I tak to niczego nie zmieni, bo jak sam napisałeś - nowa wersja nie umie odczytać danych wprowadzonych w wersji poprzedniej.
A jak będziesz potrzebował mieć dostęp do danych archiwalnych to szukasz paczki za konkretny okres, kopiujesz ją (dla bezpieczeństwa - żeby w żaden sposób nie uszkodzić posiadanych danych) i odpalasz. Masz wtedy zarówno dane, jak i aplikację w pasujących do siebie wersjach.

0

Rozwiązałeś mój problem :)! Dzięki!!!
Zapisanie w pliku wersji schematu Nazwa pliku to nr schematu i zawsze najwyższa wersja jest obowiązująca pozwoli zawsze odczytać dane z pozostałych tabel prawidłowo. Wtedy przy danej wystarczy dodać przy jakim numerze schematu została zapisana.
Tabele trzymam w csv szyfrowanych moją funkcją szyfrującą bajty i bity pliku. Przy czym każdy plik ma swój klucz w sobie i plik za każdym odczytem jest szyfrowany od nowa nowym kluczem losowym.
Tak jest mi łatwiej Niż w txt podejrzeć ewentualne błędy zapisu danych przy pisaniu procedur.

0

Furious Programming!
Rozwiązałeś mój problem :)! Dzięki!!!
Zapisanie w pliku wersji schematu Wg np. Nazwa pliku to nr schematu i zawsze najwyższa wersja jest obowiązująca pozwoli zawsze odczytać dane z pozostałych tabel prawidłowo. A tabele są od siebie zależne wielokrotnie i krzyżowo.
Wtedy przy danej w grafiku głównym wystarczy dodać przy jakim numerze schematu została zapisana. Wtedy zawsze interpreter zinterpretuje ją i przedstawi prawidłowo i bedzie mógł wydrukować np listę dyżurową z maja 2017r taką jak wyglądała w schemacie wtedy :)
Poza tym:
Tabele trzymam w *.csv szyfrowanych moją funkcją szyfrującą bajty i bity pliku czyli w simumie w plikach binarnych. Przy czym każdy plik ma swój klucz w sobie i plik za każdym odczytem I zapisem jest szyfrowany od nowa nowym kluczem losowym.
Tak jest mi łatwiej podejrzeć ewentualne błędy zapisu danych przy pisaniu procedur niż w txt bez tabelki.

0
Windowbee napisał(a):

Rozwiązałeś mój problem :)! Dzięki!!!

Zapisanie w pliku wersji schematu Nazwa pliku to nr schematu i zawsze najwyższa wersja jest obowiązująca pozwoli zawsze odczytać dane z pozostałych tabel prawidłowo. Wtedy przy danej wystarczy dodać przy jakim numerze schematu została zapisana.

Bardziej miałem na myśli zapis wersji formatu w pliku, nie w nazwie pliku, ale rób jak Ci wygodniej. Byle rozwiązanie problemu w ten sposób nie spowodowało powstania kolejnych 10 problemów przy okazji kolejnych aktualizacji.

Tabele trzymam w csv szyfrowanych moją funkcją szyfrującą bajty i bity pliku. Przy czym każdy plik ma swój klucz w sobie i plik za każdym odczytem jest szyfrowany od nowa nowym kluczem losowym.

Patrząc przez pryzmat bezpieczeństwa, nie powinieneś używać swoich algorytmów szyfrujących, a skorzystać z tych już opracowanych, przebadanych i zaimplementowanych. Do Lazarusa jest wiele bibliotek zawierających mnóstwo algorytmów szyfrujących, więc jest z czego wybierać. Ew. możesz też kompresować pliki do formy archiwum i zabezpieczać je hasłem — w ten sposób nie dość że zawartość będzie zaszyfrowana, to w dodatku porządnym algorytmem.

0

Tak czy inaczej mega dziękuję.
Po nazwie Pliku program szybciej odnajdzie właściwą wersję i załaduje schemat odpowiedni do interpretacji danej z np grafiku , mało tego sam szybko w notatniku schemat bede mógł podejrzeć gdyby był trudny do znalezienia błąd.
Pliki schematów są małe i zmieniają się nie codziennie więc nie zajmą dużo miejsca.
Co do szyfrowania zalarusowego nic nie umiem musiałbym znów nad tym ślęczeć a procedury, dobrze dla moich potrzeb ,szyfrujące już dawno napisałem i wiem jak to robilem po każdym bajcie pliku szyfrowanego. Chętnie bym sprawdził czy ktoś rozszyfruje co jest napisane gdybym wkleił znaczki z pliku txt po zaszyfrowaniu 😁

1

U mnie dane nie giną zgadza się to elementarz — Windowbee dziś, 19:07

No tak, ale sam mówisz jednak giną, dane (wydziały) lub ich związki (związek z wydziałem był od .. do)
Jak powiem, że to jest do jasnego wyrażenia w bazie danych, to zaraz mnie "skorygują", ze w "plikach też się da". Da się, ale to będzie koszmar.

Sorry Winnetou, ale kwestia "naumienia się SQL", to nie poznanie elementarza, ale myślenie przeniknięte możliwościami relacyjnych baza danych, wykorzystywanie możliwości i unikanie pól minowych.

To by się rysowało jakoś tak:
Osoba <--- OsobaWydział (id osoby, id wydziału, od, do) -> Wydział (w tym pole aktywny od ... do )

Za osobę podstaw dowolny zasób (leżankę, pomieszczenie, itd)
Postawienie Wydziału w stan spoczynku aktualizuje związki (też ustawia datę końcową)
Odbyte i Planowane Dyżury odnoszą się do środkowej tabeli, nie da się ich dopisać poza zakresem czasowym.
W tej strukturze osoba może się przemieszczać miedzy wydziałami (prawda, że ważne)

i tak dalej .... i tak dalej ...

trzymanie w plikach ma wielką wadę, że kiedyś JEDNAK się zapomni o przygotowaniu do upgradu, i zostaną pliki których naprawdę nie ma czym zinterpretować.
Bazę ugraduje z wersji na kolejną, niczego nie pominiesz
(na marginesie: tu popularny błąd początkujących tabela na każdy miesiąc itd, temu mówimy stanowcze NIE)

Zawsze bym się bał o integralność archiwum z pierdyliardem plików. Skąd wiesz, że 1.5 roku wstecz nie miał szczęścia być na uszkodzonym sektorze, albo na pendraku. Potem go trzymasz, wierząc, że jest OK.

Tak jest mi łatwiej podejrzeć ewentualne błędy zapisu danych przy pisaniu procedur niż w txt bez tabelki.

Wiesz co, jak sprzedawałem znajomemu PF 126p, to byłem dumny, że był cały bagażnik części zapasowych. To naprawdę bardzo dobry samochód, jeśli się ma j/w i klucz 10/12 i 13/17
Czujesz podobieństwo argumentacji?

ale nie można prawidłowo wyświetlić bez zapamiętsnia schematu ich wyświetlania z przed zmiany — Windowbee dziś, 19:07

Plików nie widziałem, ale coś z nimi kombinujesz.
Przeciwstawiając: baza danych jest samodokumentująca się (w sensie, o którym by tzreba dłużej porozmawiać)

0

nie, nie o to chodzi , dane nie giną one są i pozostają ale odnoszą się do nie istniejącego już np. pionu dyżurowego( który np. zlikwidowano) można je odczytać ale bez schematu jak tą daną interpretować i jak przedstawiać, to wiadomo tylko ,że np. dana osoba pracowała x godzin takiego a takiego dnia ale nie wiadomo gdzie bo już schemat się zmienił i np. tego oddziału czy stanowiska już nie ma. Poza tym to stanowisko mogło nawet nie tyle zniknąć co być przeniesione do zupełnie innego działu, oddziału itd i dane byłyby błędnie interpretowane i przedstawiane w subgrafikach

0

Nie kłóćcie się, bez sensu. Sposobów jest mnóstwo byle były skuteczne i prowadziły do stabilnego celu

2

Tylko czy baza danych podobnie jak plik nie może ulec uszkodzeniu? Tylko że wtedy tracimy całość danych a tak tylko pojedynczy plik interpretacji danych z jakiegos okresu — Windowbee 2 minuty temu

Po pierwsze baza, nie będąc bazą plikową (SQLlite) jest odcięta od aktywnego loginu, nie zaszyfruje jej wirus ani zmęczony pracownik nie wciągnie na notepad.
Po drugie może się automatycznie backupiowac nie przeszkadzając w pracy.
Po trzecie sama z siebie szybciej zgłosi problem i niż jeden z pierdyliarda plików
Po czwarty jak uszkodzisz jeden centralny plik to ...

I tak dalej, i tak dalej.
Ale samouk takich platform, jeszcze nie spotkałem, który by wyszedł poza swoją działkę. jak się nauczył DBF, to będzie DBF do śmierci itd

Dla mnie EOT, tu nikt nikogo nie przekona

0

Bazy danych są zapewne świetne ale mam jedno życie :) nie ogarnę ich bez dużego zaparcia i ćwiczeń z nimi co zniechęca trochę bo nie widać efektów swojej pracy,mój program nie jest tak wielki i jego pisanie ma sprawiać mi przyjemność i stanowić łamigłówki logiczne. Takie ćwiczenie Głowy i zapominanie o zgonach...
A większość problemów o jakich piszesz i ważność danych jest do obejścia z użyciem plików. Zwłaszcza że ich kopie będą /są przechowywane na komputerach łączących się z matką. I jest procedura sprawdzająca spójność systemu plików alarmująca o błędzie lub uszkodzeniu działająca w wątkach subprogramu uruchomionego w tle. Dysk może się uszkodzić zarówno z plikiem jak i bazą.

0
Windowbee napisał(a):

Bazy danych są zapewne świetne ale mam jedno życie :)

To lecz ludzi, czytaj the Lancet czy co tam się czyta ...

1

Skasujcie pls proszę mój post tylko wstyd wyszedł z tą dyskusją i lekkim poziomem agresji. Ale dzięki za podpowiedź to zadziała. Przy każdej danej info jaki nr schematu ją interpretuje. :) zapis schematu z nr przy zmianie i zadziała - nie elegancko jak profesjonalista ale zadziala jak przez ost 7 lat.

1 użytkowników online, w tym zalogowanych: 0, gości: 1