[ZukColorado]

Mirki, robię system rezerwacji biletów i myślę, jak rozwiązać pewien problem. Od strony admina wygląda to tak, że dodaje się przystanki (tabela stop z id i nazwą) oraz trasy (tabela track z id, nazwą, id przystanku początkowego i końcowego). Teraz na podstawie tras układa się rozkład jazdy - wybiera się dzień i trasy dla tego dnia. Oczywiście to tak w dużym skrócie, bo jest jeszcze kilka warstw abstrakcji (po to, żeby ogarnąć trasy kierowcy w danym dniu, godziny odjazdów i przyjazdów, ceny, itp.), ale nie ma to znaczenia dla pierwotnego problemu.

Gdy admin ułoży rozkład na dany dzień, to ma on obowiązywać w tej właśnie wersji. Czyli gdy ktoś teraz zmieni nazwę przystanku, nazwę trasy czy nawet jej przystanek początkowy i końcowy, to już przydzielony rozkład ma pozostać bez zmian. Odpada więc proste dołączenie w rozkładzie kluczy obcych np. do tras.

Myślałem nad następującymi rozwiązaniami:

1. Zablokowanie edycji przystanków/tras - rozwiązanie najłatwiejsze i w przypadku przystanków nawet sensowne (bo wiadomo, że przystanek "Rzeszów" nie powinien stać się nagle przystankiem: "Kraków"), jednak w przypadku tras wymuszałoby to na administratorze ręczne dodawanie nowych rekordów, co niekoniecznie byłoby wygodne (zwłaszcza, że są kolejne warstwy abstrakcji, o czym pisałem).

2. Odkładanie danych aktualnych na moment układania rozkładu w tabeli z rozkładem. Wtedy zamiast kluczy obcych w tabeli z rozkładem zapisuję nazwy przystanków, tras, itp. Wadą jest duża redundancja i utrudnione raportowanie (żeby raportować np. odjazdy z danego przystanku musiałbym dokonywać agregacji po polach tekstowych).

3. Przerobienie edycji przystanków i tras tak, aby w rzeczywistości dodawały nowy rekord (z nowym ID) powiązany z poprzednim, zamiast zmiany obecnego. Stary rekord byłby natomiast oznaczany jakąś flagą i ukrywany. W ten sposób mógłbym w tabeli z rozkładem korzystać z kluczy obcych, bo dane rekordów przystanków i tras tak naprawdę nigdy by się nie zmieniały. W tej chwili nie potrafię przewidzieć negatywnych konsekwencji tego rozwiązania.

Które rozwiązanie wydaje Wam się najlepsze? Bardzo chętnie poczytam też Wasze pomysły na rozwiązanie tego problemu.

#sql #bazydanych #webdev

[Mikunda]

@ZukColorado: a może nie stosować nazwy przystanku jako GUID tylko traktować nazwę jako osobną wartość elementu.

[G.....n]

@ZukColorado: Po prostu edycja trasy nie edytuje danych, tylko dodaje nową trasę, a starą oznacza jako archiwalną.
Wadą rozwiązania jest komplikacja operacji na bazie.

[ZukColorado]

@Mikunda: przystanki są tylko jednym elementem, są jeszcze trasy i kolejne warstwy abstrakcji, więc bardziej chodziło mi o jakiś sposób podejścia do tematu.

@Ginden: OK, czyli podejście trzecie. Dzięki.