Jak przechowywać niestandardowe pola użytkownika w bazie danych

Question

Próbuję znaleźć samouczek, który poprowadzi mnie w jaki sposób działają niestandardowe pola użytkownika. Podobnie jak w witrynach ankiet, gdzie pozwalają użytkownikom tworzyć niestandardowe pola i przechowywać je, a co ważniejsze przechowywać dane wprowadzone przez te pola.

Szukam czegoś, co opisuje, jak to zrobić w bazie danych. Mam trochę problemów ze znalezieniem sposobu, który nie zabrałby na zawsze pobierania tych danych, gdy użytkownicy będą je wypakowywać do plików excel/cvs.

Answer 1

Obiekt Entity-Attribute-Value model jest zwykle używany do obsługi tego scenariusza w relacyjnej bazie danych. Szybkie wyszukiwanie "modelu EAV" przyniesie więcej informacji, niż będziesz wiedział, co zrobić.

Answer 2

Szósta forma normalna to formalny sposób na wdrożenie tego. Idź z 3NF dla wszystkich tabel i 6NF dla jednej lub dwóch tabel, które chcesz dodać kolumny bez zmian DDL. Używaj oszczędnie.

EAV to bękartowy syn 6NF. Oznacza to, że ludzie, którzy to robią i piszą o tym, nie mają formalnego zrozumienia 6NF, więc często tworzą potworności.

Oczywiście należy zachować dobre standardy: należy używać typów danych; Deklaratywna integralność referencyjna (klucze obce); itp. Nie dawaj im niczego. Uciekaj jak diabli od tego, że ktoś ci mówi, że musisz je oddać.

6NF/EAV jest bardzo szybki, nie ma przeszkód w korzystaniu z możliwości ustawiania parametrów serwera. Ponownie, uciekaj jak diabli od każdego, kto powie ci, że musisz używać przetwarzania wiersz po rzędzie lub kursorów, lub że nie możesz z łatwością budować kolumn z rzędów. Napisz ponownie, jeśli masz konkretne problemy.

Wymaga to wykraczania poza bieżące możliwości (sterowanie, DDL) SQL; aby to zrobić w kontrolowany sposób i uniknąć tworzenia niemożliwych do zapamiętania potworów, potrzebujesz małego katalogu, aby zawrzeć metadane. Jeśli jesteś sprytny, możesz go użyć do wygenerowania zapytania SQL, które będzie wykorzystywane do odpytywania, a tym samym wyeliminować wiele ręcznych robót.

Istnieje wiele dezinformacji, a niektóre osoby z "rep" nie mają pojęcia. Aby odnieść sukces z technicznego punktu widzenia, potrzebujemy dokładnych informacji, a nie mitów i marnowania strachu. Być może zainteresował Cię ostatni post, w którym próbowałem uzyskać set the recond straight.

Answer 3

Dla każdej tabeli używamy 3 tabel, w których musimy obsługiwać pola zdefiniowane przez użytkownika. Tak na przykład, jeśli chcesz zastosować to do stolika Survey, można utworzyć:

SURVEY_ATTRIBUTE 
- SurveyAttributeId 
- SurveyAttributeName 
- SurveyAttributeType 

SURVEY_ATTRIBUTE_CHOICE 
- SurveyAttributeChoiceId 
- SurveyAttributeChoice 
- SurveyAttributeId 

SURVEY_ATTRIBUTE_VALUE 
- SurveyAttributeValueId 
- SurveyId 
- SurveyAttributeValue 

SURVEY_ATTRIBUTE tabela przechowuje jeden rekord za atrybutu niestandardowego. Tabela SURVEY_ATTRIBUTE_VALUE przechowuje atrybuty faktycznie przypisane do ankiet. Jeśli atrybut nie ma zastosowania do serveya, nic nie jest przechowywane. Tabela SURVEY_ATTRIBUTE_CHOICE przechowuje wszystkie dozwolone opcje atrybutów typu "LISTA".

Pole SurveyAttributeType w tabeli SURVEY_ATTRIBUTE służy do opisu typu atrybutu. Używamy tylko niewielkiej liczby dozwolonych typów, takich jak CHAR, DATE, NUMBER, LIST. W zależności od tej wartości nasza aplikacja wie, co zrobić z wartością przechowywaną w polu SurveyAttributeValue. Możesz oczywiście sformalizować to dalej, aby umożliwić szerszy zakres, określić maksymalną długość pola itp., Wszystko zależy od poziomu swobody, jaki chcesz dać użytkownikowi końcowemu. Staramy się, aby było to jak najprostsze, ponieważ docelowi odbiorcy nie są administratorami baz danych, ale użytkownikami końcowymi, zazwyczaj nie przejmują się długością pola i tym podobne.

Można również pominąć tabelę SURVEY_ATTRIBUTE_CHOICE i zapisać dopuszczalne wartości w ciągu XML w polu SURVEY_ATTRIBUTE. To będzie zależeć od sposobu, w jaki zamierzasz wprowadzić w swojej aplikacji.