Najbardziej efektywny kodowo sposób obsługi danych oznaczonych jako „końcowe” w porównaniu z danymi, które mogą powodować zmiany - ruby-on-rails, baza danych, projektowanie baz danych, struktury danych, activerecord

Mam kilka modeli, których rekordy ORAZ skojarzenia mogą mieć dwa stany, które muszą zostać utrwalone. Wersja ostateczna i wersja robocza.

Oto trochę więcej szczegółów: Jeśli model to „formularz wniosku”, a użytkownik przesyła ostateczny formularz wniosku, muszę go przechowywać i mieć możliwość odzyskania tego ostatecznego formularza wniosku.

Jeśli w późniejszym terminie użytkownik zechce zmodyfikowaćten „formularz wniosku”, następnie muszą edytować kopię roboczą tego ostatecznego rekordu, dopóki nie przedstawi on nowej ostatecznej wersji. Oznacza to, że nie może edytować poprzedniego ostatecznego formularza wniosku, dopóki nie zaznaczy pola „ostateczna”, w którym to momencie wersja robocza stanie się nową ostateczną wersją.

Chodzi o to, że zarówno wersja ostateczna, jak i wersja robocza mają powiązania muszą być przechowywane wraz z powiązanymi z nimi zapisami. Oznacza to, że powiązane z nimi zapisy (np.aplikacja ma wiele osób kontaktowych) musi być przechowywana w sposób umożliwiający wyszukanie z wersji ostatecznej i roboczej, bez pomieszania kontaktu „ostatecznego” z kontaktem „szkicowym”.

Obecnie przychodzą mi do głowy dwa sposoby rozwiązania tego problemu:

• Skorzystaj z ActsAsAudited i skontroluj tylko wersję ostatecznądokumentacja. Zapytanie o finały, kiedy tylko ich potrzebuję. (Istnieje rozwidlenie ActsAsAudited, które również śledzi powiązania). Następnie przeszukaj tabele audytu, aby uzyskać najnowsze rekordy.
• Użyj dwóch równoległych zestawów tabel danych: jednego, który przechowuje wersje robocze, a drugiego, który przechowuje tylko ostateczne kopie.

MYŚLĘ, że trzymanie finałów i szkiców w tej samej tabeli może powielić przeznaczenie tych tabel i sprawić, że struktura będzie trudniejsza do naśladowania.

Czy znasz inny schemat lub strategię, które bardziej elegancko rozwiązałyby problem? A może to zmniejszyłoby złożoność kodu?

Oto podobne pytanie, które zakończyło się skorzystaniem z drugiej opcji powyżej:

Wersja robocza tabeli bazy danych

Bernie

Odpowiedzi:

2 dla odpowiedzi № 1

Chodzi o to, że zarówno wersja ostateczna, jak i wersja robocza mają skojarzenia, które muszą być zsynchronizowane

Jak może kiedykolwiek zmienić się ostateczna wersja? Ostateczne wersje powinny być niezmienne.

Czy masz na myśli, że ktoś może sporządzić i przesłać dokument, podczas gdy inni użytkownicy tworzą wersje robocze?

Jeśli tak, wydaje się, że kontrola źródła ma zastosowanie. Przydatne byłoby podejście typu wiki do łączenia dokumentów lub prosta zasada „blokowania”, aby dwóch użytkowników nie było w konflikcie.

Jeśli chodzi o przechowywanie wersjonowanego dokumentu, jeśli dyskontujesz za pomocą systemu plików i chcesz użyć konwencjonalnej bazy danych, istnieją dwa główne podejścia:

1. umieść to wszystko w jednej tabeli, z flagą dla wersji roboczej | ostatecznej i flagą dla „nagłówka” - najnowszej ostatecznej wersji każdego dokumentu

2. trzy tabele: tabela „głów”, osobna tabela szkiców i trzecia tabela z historycznymi wersjami ostatecznymi

Przewagą jednego podejścia nad drugim będzie wydajność i dystrybucja, jeśli system stanie się naprawdę duży.

Ale jeśli system jest mały, polecampierwsze podejście - pojedyncza tabela - być może z finezją trzech „widoków”, aby migracja do bardziej skomplikowanego podejścia opartego na trzech tabelach w wersji 2.0 była mniej bolesna.

---