jaka jest najlepsza implementacja formowalnych i modyfikowalnych formularzy internetowych klienta w relacyjnej bazie danych?

Question

W kilku projektach aplikacji internetowych, w których uczestniczyłem, klient prosi o możliwość tworzenia własnych formularzy. Powstaje pytanie, jak przechowywać definicje formularzy, a następnie, jak przechowywać wartości wprowadzone przez użytkownika w tych niestandardowych formularzach.

Widziałem to zrobić na dwa sposoby:

1. Zakładając, że klient określa tylko, jak wielu dziedzinach i jakie etykiety związane są z tych dziedzinach; możemy znaleźć rozwiązanie obejmujące cztery tabele. FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues. Klient wprowadza zmiany do FormDefinition i FormFieldDefinition, a aplikacja internetowa wykorzystuje te informacje do renderowania formularza internetowego HTML, na którym użytkownik strony (użytkownik końcowy) prześle formularz, w którym zostanie utworzony nowy wiersz w numerze FormInstances, a wartości są zapisane w tabeli FormFieldValues.

   Wiersze w FormDefinition określa postać, tj form definition ID = 2, form title = 'Car Registration Form'. Wiersze w FormFieldDefinition definiują pola formularza w FormDefinition, tj. field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'. Wiersze w FormInstance to instancja każdego formularza wypełnionego przez użytkownika, tj. definition id = 2, date_entered = '2008-09-24'. I wiersze w FormFieldValues są wpisami użytkownika, tj. field definition = 7, value = 'Tiburon'.

   Niestety, oznacza to, że wartość w kolumnie FormFieldValues musi być typu char największego możliwego rozmiaru, który klient może określić w formie internetowej ... i kiedy zmienić definicje form, zarządzanie starych danych staje się niepewna. Ale wpisy użytkowników są możliwe do sprawdzenia (napisałem quick query, który zawiera wpisy użytkowników o identyfikatorze formularza, który jest podobny do another pivot question).

2. Alternatywą dla używania czterech tabel byłoby serializowanie definicji formularzy i formularzy formularzy użytkownika w formacie XML (lub YAML lub podobnym) i zapisywanie ich jako tekstu. Plusem jest to, że formularze są czytelne dla człowieka w bazie danych. Wadą jest to, że będzie więcej narzutów aplikacji przy analizie XML, a baza danych stanie się znacznie mniej dostępna z punktu widzenia SQL.

Moje prawdziwe pytanie brzmi: jak nazywa się ten model bazy danych? (Mogę google rozwiązać ten problem.) Ale chciałbym udzielić odpowiedzi na pytanie: która jest lepsza implementacja lub czy istnieją lepsze (lub równie dobre) implementacje?

Answer 1

To, co opisujesz, jest często nazywane "wartością atrybutu jednostki" i czasami jest określane jako "mieszanie danych i metadanych". Oznacza to, że nazwy atrybutów (pól) są przechowywane jako ciągi (dane).

Prowadzi to do wielu złożonych problemów, takich jak upewnienie się, że każda instancja formularza zawiera ten sam zestaw pól lub upewnienie się, że pola obowiązkowe są wypełnione (odpowiednik NOT NULL w konwencjonalnej tabeli).

Zapytałeś, jak najlepiej to zrobić z relacyjną bazą danych. W relacyjnej bazie danych należy używać metadanych dla metadanych. W tym przypadku oznacza to tworzenie nowych tabel dla każdego formularza i użycie kolumn dla pól formularza. Tak więc definicja formularza jest po prostu metadanymi tabeli, a jedna instancja formularza to jeden wiersz w tej tabeli. Jeśli obsługujesz formularze z odpowiedziami wielowartościowymi (np. Pola wyboru), potrzebujesz również tabel zależnych.

Może wydawać się to kosztowne lub trudne do skalowania. Prawdopodobnie prawdziwe. Relacyjna baza danych może nie być najlepszym narzędziem do tego zadania. Wspomniałeś o możliwości XML lub YAML; w zasadzie jakiś zorganizowany format pliku, który można zdefiniować ad hoc. Należy zdefiniować DTD dla formularza każdego klienta, aby każda zebrana forma mogła zostać zweryfikowana.

edit: Jeśli naprawdę potrzebujesz elastyczność EAV w aplikacji, to jest w porządku, są zwykle okoliczności, które uzasadniają łamanie zasad. Po prostu pamiętaj o dodatkowej pracy, jaką wykonujesz, i zaplanuj to w swoim harmonogramie rozwoju i skalując serwer do obsługi obciążenia. Zobacz także inny answer of mine about EAV na StackOverflow.

Answer 2

Jak nazywa się ten model bazy danych?

Nie wiem, jak to właściwie nazwać, ale jest to ten sam proces, który stosuje się do dynamicznego generowania ankiet. Jeśli szukasz źródła do generowania aplikacji ankietowych, znajdziesz ten sam ogólny schemat bazy danych, a także podobne metody.

Zobacz także na stronach tworzenia formularzy, takich jak http://wufoo.com/ lub http://frevvo.com/ dla pomysłów interfejsu użytkownika (jeśli robisz to w Internecie).

Answer 3

Istnieje trzecia opcja, w której można tworzyć tabele i dodawać kolumny w razie potrzeby. Zależy to od tego, ile formularzy jest tworzonych, ale bazy danych mogą z łatwością obsługiwać wiele tabel. Jeśli więc użytkownik chce dodać formularz "Formularz rejestracyjny samochodu", dodaje się tabelę "CarRegistrationForm". Dla każdego pola, które chcą w formularzu, możesz pozwolić im wybrać między podstawowymi typami, takimi jak data, int i tekst. A kiedy tekst jest wybrany, muszą wprowadzić maksymalną długość z listy wyboru, która daje ci informację, czy pole powinno być varcharem, czy też klonem.

Działa na serwerze SQL Server, w którym można łatwo dodawać i usuwać kolumny. W przypadku DB2 może to stanowić problem, ponieważ kolumna kropli nie jest zaimplementowana. Dla mysql nie jestem pewien.

Nadal musisz zarejestrować swoje formularze i pola w dwóch oddzielnych tabelach.

Answer 4

Prawdopodobnie chcesz Entity-Relationship Model

Istnieje rzeczywiście GUI narzędzia do tworzenia schematu interaktywnie z takich modeli.