Jak zaprojektować zapisywanie niekompletnych danych wprowadzonych przez użytkownika?

Question

Mamy aplikację Dot Net Win formularzy, która ma niewiele formularzy z więcej niż 40 pól do wypełnienia.

Po wypełnieniu przez użytkownika 25 pól, a następnie zdaje sobie sprawę, że musi uzyskać więcej danych, zanim będzie mógł zapisać informacje lub wprowadzi wszystkie dane, ale ich jest jakiś błąd sprawdzania firm, w którym należy skontaktować się z kimś innym przed dokonaniem korekty.

W takich sytuacjach chciałby zapisać niekompletne lub niepoprawne dane w tymczasowym przechowywaniu danych i pobrać je później, gdy ma dane do zakończenia operacji składowania.

Proszę dać mi znać, jaki byłby najlepszy sposób realizacji tego?

on kilka opcji Rozważaliśmy:

1) Utwórz XML blob i zapisać na swoim komputerze lokalnym (Ale, użytkownik może potrzebować go z innego urządzenia)

2) Utwórz zduplikowanych tabel do przechowywania nieważny dane (ale uważam, że nieprawidłowe dane nigdy nie powinny być częścią mojej bazy danych)

Answer 1

Można zatrzymać formularz częściowy na XML i zapisać XML do tabeli bazy danych, która ma również identyfikator użytkownika i identyfikator formularza. Gdy użytkownik wyświetli formularz na oryginalnym komputerze lub innej maszynie, system wykryje częściowe dane i wyświetli monit o przeładowanie/zignorowanie/usunięcie go. Potrzebna byłaby tylko jedna tabela dla wszystkich użytkowników formularza &. Oddzielne tabele dla każdego obiektu bazy danych byłyby niepotrzebne.

Answer 2

Można umieścić wszystkie nieprawidłowe dane jako zwykły tekst/xml w jednej tabeli bazy danych. Prawdopodobnie nigdy nie musisz sortować/wyszukiwać niekompletnych danych. Może to łączyć zalety obu twoich pomysłów.

Answer 3

W jaki sposób przechowujesz dane, gdy użytkownik odsyła je w celu sprawdzenia poprawności? Czy przechowujesz go w sesji? Czy możesz zapisać tę część sesji do swojej bazy danych i przywrócić ją, kiedy chce zakończyć pracę?

Jeszcze jedna myśl polega na podzieleniu formularzy na poddziały, które zostaną zapisane przed kontynuowaniem. Forma 40 pól wydaje się być zbyt wygórowana i może również prowadzić do trudnych w użyciu aplikacji.

Answer 4

J D stanowi doskonały punkt. Ten interfejs użytkownika brzmi jak zadanie dla kreatora. W ten sposób są 3 strony, zanim zorientują się, że potrzebują więcej danych, i wiesz, że dane są ważne, ponieważ sprawdzasz poprawność strony po stronie.

Answer 5

powiedziałbym iść z drugiej opcji, ale związać niekompletne dane do sesji w ten sposób można zyskać 2 rzeczy:

1) niepełne dane wygasną, gdy sesja wygasa 2) nie będzie jasne połączenie, którego danymi jest właścicielem, przez którą sesję (użytkownik)

Nie sądzę, że jest coś złego w przechowywaniu go w bazie danych, o ile upewnisz się, że jest okresowo czyszczone (w tym przypadku po wygaśnięciu sesji). Powodzenia

Edycja: jeśli chcesz, aby był dostępny w całej sesji, powiązaj go z użytkownikiem i wygaś go, gdy będzie kompletny.

Answer 6

1) niepełne dane wygasną gdy sesja wygasa

Użytkownik chce Niekompletne dane dostępne dla swojego loginu całej sesji.

Answer 7

Myślę, że należy ono do osobnej tabeli. Z biznesowego punktu widzenia jest to IncompleteWidget. Po zapisaniu i sprawdzeniu poprawności jest przechowywany w tabeli Widget.

Mapowanie może wydawać się trochę uciążliwe, ale myślę, że w tej sytuacji ma to sens.

Answer 8

Możliwe, że jest kontrowersyjny, ale: przechowuj niekompletny obiekt w tej samej tabeli bazy danych, w której ma być przechowywany gotowy obiekt.

Niekompletne i kompletne obiekty należą do dokładnie tej samej klasy i znajdują się tylko na różnych etapach ich życia. Możesz użyć pola statusu, aby wskazać, czy obiekt został jeszcze sprawdzony. Rozwiązuje to problem, nie wprowadzając zupełnie nowego mechanizmu do debugowania i utrzymywania.