Witam. Tworzę aplikację dzienniczka elektronicznego i stanąłem na etapie pobierania danych zarchiwizowanych czyli takich które będą dostępne po zamknięciu roku szkolnego bądź semestru. Czy w takim przypadku rekordy wymagające archiwizacji (oceny, listy obecności itp) musiałbym w jakiś sposób kategoryzować czyli tworzyć kategorie ( np. semestr 1, 2, 3 itd.) do których przydzielałbym dane przed zamknięciem roku szkolnego/semestru? Dodam że aplikacja ma za zadanie obsłużyć wiele szkół więc każda ze szkół będzie samodzielnie wybierać moment zamknięcia roku bądź semestru.
Po analizie bazy danych stwierdziłem że archiwizacji powinny podlegać dane takie jak: lista obecności, lista ocen, średnie semestralne i ewentualnie plany zajęć.
Nie będę wrzucał screena bazy danych bo jest dosyć rozbudowana i połączenia między tabelami nie są dobrze widoczne. Baza danych jest relacyjna ale nie wiem czy jest to przydatna informacja. Jeżeli będzie konieczne to wrzucę screeny tabel odpowiedzialnych za przechowywanie np. ocen.
Każda sugestia będzie pomocna.

Edit:
Przeglądając nasze forum natknąłem się na informacje, że dane są kategoryzowane pod względem semestru (semestr1, semestr2). Wszystko byłoby fajnie z tym że muszę nauczyć skrypt rozróżniania semestrów pod względem roku. Mógłbym stworzyć tabelę "szkola_semestry" i w niej zapisywać aktualną datę semestru czyli przykładowo: semestr 1, 2017-01-09 ale nie ma to sensu, gdyż administrator z roku na rok musiałby dodawać nowe rekordy do bazy danych.

Wydaje mi się, że jakoś demoinizujesz z tą archiwizacją. Wystarczy data rekordu i już wiadomo z którego semestru jest rekord. Operator mógłby wpisywać datę zamknięcia danego semestru. Taka data by wystarczała do odróżnienia rekordów z danego sem. od pozostałów rekordów.

Co się tyczy, który semestr, to wystarczy unikalne id semestru, by się semestry nie myliły. Myślę, że baza danych powinna być uboga, ale wystarczająca do odpowiedniego pobierania danych.

http://forum.php.pl/index.php?s=&showt...t&p=1222747

Wystarczy dodać wyszukiwanie po dacie lub zakresie dat a przecież semestry są stałe, idą z kalendarza. Jak masz na stronie listę zajęć to może być np. URL:
/classes.php?year=1978&semester=2 (czyli rok rozpoczęcia roku szkolnego to 1978, semestr 2) który wyświetli na stronie listę zajęć

Żaden problem też ustawić, by dostęp do semestrów innych niż aktualne wymagał np. dodatkowych uprawnień. Po co jakieś kategorie?

Udało mi się rozwiązać ten problem. Utworzyłem tabelę danych "semestry_podzial"
semestry_podzial:
Id_Semestr_Podzial [PK]
Semestr1_Od
Semestr1_Do
Semestr2_Od
Semestr2_Do
Id_Szkola [FK]
Przykładowe dane: 1 | 01.09 | 23.03 | 24.03 | 18.06| 2
Następnie napisałem algorytm który pobiera rekordy i w pętli je kategoryzuje (uwzględnia również lata) czyli np 2017/2018 (sem. zimowy), 2017/ 2018 (sem.letni) itd. Chodziło mi o pobranie zakresu rekordów zależnie od semestru i roku, przy wyborze opcji z pola typu select dla danego przedmiotu i danej klasy.
Teraz mam inny problem. Zastanawiam się w jaki sposób mógłbym rozwiązać problem przenoszenia ucznia jeżeli nie otrzyma promocji do następnej klasy. Czy mam zmieniać mu id klasy do której zostanie przydzielony w przyszłym roku czy utworzyć tabelę "uczniowie_nieklasyfikowani" i tam tworzyć listę uczniów którzy nie uzyskali promocji do następnej klasy? Następnie z tej listy inni wychowawcy mogliby wybierać uczniów którzy będą w ich klasie.

Uczeń jako osoba i uczeń w konkretnej klasie to powinny być 2 różne osobne tabele pozostające jedynie w relacji.
Nazwisko, płeć, pesel nie zmieniają się, natomiast numer w dzienniku, klasyfikacja itp zmienia się co rok lub semestr.

A po co go gdzieś przenosić? Jak się tworzy nową klasę to wpisze się do niej tego ucznia jeszcze raz. Gorzej z przenoszeniem uczniów z klasy do klasy lub nawet innej szkoły, ale też nie jest to zbyt trudne (pod warunkiem dobrze zaprojektowanego modelu danych).
- płeć i pesel pewnie tak, ale z nazwiskami bywa różnie, niekiedy uczennice wychodzą za mąż

Przenoszenie to wciąż relacja osoby do tabeli z uczniami.
Co do nazwiska jeżeli jest to istotne faktycznie aby wiedzieć jakie miała nazwisko w danym semestrze to można to zawierać także w tabeli z uczniami.
Można też przechowywać oba nazwiska ale nie znamy momentu ich zmiany.

NIe badzcie "rasistami" ( )
1) By uczennica zmienila nazwisko nie musi wychodzic za maz. Moze tez zmienic i bez tego
2) uczen ten moze zmienic nazwisko i tak, tez bez hajtania sie

Jesli zmiana historia nazwiska jest tak bardzo wazna, to dodajcie dla usera historie zmian ale nie kombinujecie ze zbednymi polami w klasach czy gdzie tam to chcecie wstawiac

Historię zmian uwzględnię tylko przy zmianie nazwy klasy żeby aplikacja mogła pobierać informacje o poprzednich latach, jeżeli ktoś będzie chciał przejrzeć oceny z innych lat. Rejestrację innych zmian sobie odpuszczę bo nie mam za bardzo czasu na to (Projekt zaliczeniowy do licencjatu). Chodzi mi o to żeby wypisać ucznia z aktualnej klasy ale coś się musi z nim później dziać. Nie chodzi mi o prawidłowy zapis danych w bazie bo wszystko jest oparte o tabele łącznikowe i relacje. Chcę żebyście mi podsunęli pomysł co zrobić z uczniem jeżeli reszta klasy otrzyma promocję a jeden uczeń nie. W mojej bazie danych do klasy jest przypisany nauczyciel, który później dodaje nowych uczniów do swojej klasy. Żeby zwiększyć nazwę klasy( np. z 1C na 2C) to Nauczyciel musi zmienić nazwę klasy(zrobię jakąś funkcję aktualizacji przyciskiem) bo nie widzę sensu robienia update z id klasy gdyż inni uczniowie z automatu otrzymają nowe id klasy co będzie jednoznaczne ze zmianą nazwy klasy.
Jeżeli chodzi o stan projektu to można w nim dodawać dane na chwilę obecną(na jeden semestr). Nie dodałem jeszcze reguł dla uwzględnienia poprzednich semestrów bądź lat ale z tym wiem jak sobie poradzić.