Umożliwianie użytkownikom końcowym dynamicznego dodawania kolumn do tabeli

Question

Pracujemy nad aplikacją .NET z zapleczem SQL Server. Klient żąda możliwości dynamicznego dodawania niestandardowych atrybutów do jednostek po wdrożeniu aplikacji.

Zgodnie z sugestią in a similar question możemy utworzyć tabelę, która będzie zawierać wiersz dla każdej wartości atrybutu niestandardowego (model Entity-attribute-value). Rozważamy jednak umożliwienie użytkownikom końcowym rzeczywistej modyfikacji tabeli (also suggested w tym samym pytaniu), tj. Dodawanie i usuwanie kolumn.

(Edit: jak zauważył w komentarzach, DDL nie byłyby wykonywane bezpośrednio przez użytkowników lub aplikacji, ale za pośrednictwem procedur przechowywanych, zapewniając, że wszystko przebiega sprawnie)

Główne powody to:

• Zwiększona wydajność/atrybuty wyszukiwania
• Atrybuty prawie zawsze muszą pojawiać się jako kolumny np. w siatce danych w interfejsie użytkownika lub podczas wyodrębniania danych do dalszego przetwarzania w Excel/PowerPivot.
• Dane są silnie wpisany (w przeciwieństwie do przechowywania wszystkich wartości atrybutów jako varchar)
• Uproszczony model danych

Czy są jakieś zastrzeżenia, że ​​powinniśmy być świadomi?

Rzeczy, które przychodzą na myśl to:

• Backup/operacje, które mogą być w stanie sprostać zmieniającym się struktura danych
• zależnych obiektów (takich jak widoki), które nie są prawidłowo aktualizowane w celu odzwierciedlenia przywrócić te zmiany (widok zależny musiałby wykonać select * from table, aby uwzględnić dowolne dodane kolumny).
• ...

Wszelkie dane wejściowe dotyczące tego podejścia jest bardzo mile widziane.

Answer 1

Pracuję z aplikacji firm trzecich, które obsługuje to w różny sposób:

1. Większość tabel mają „niestandardową” wersję tabeli z różnych dziedzin, aby utrzymać ogólnie nazwanych typów danych: liczba1 Date26 , Text3 itd.). Tak więc istnieje firma i spółka, które mają stosunek 1-1.

2. Listy są tworzone w tabeli, która ma ID listy (i odpowiedni sposób dla użytkowników do ustawienia schematu) i klucz obcy do połączenia z główną tabelą. Ta tabela ma kilka ogólnych kolumn, takich jak # 1.

3. tworzyć własne tabele

4. tworzyć własne poglądy i procedur przechowywanych i zarejestrować je w aplikacji. Te zestawy danych mogą być dołączane do sieci danych i/lub wykorzystywane w niestandardowych raportach.

Istnieje interfejs umożliwiający użytkownikowi etykietowanie kolumn według własnego uznania (tzn. Text1 = "Blah Blah Blah").W tej sytuacji jest mnóstwo zmarnowanych pól (chociaż moja firma zdołała wykorzystać większość pól, w tym Money47) i nie jest idealna do wydajności, nie można pokonać prawie nieograniczonej elastyczności, którą mamy.

Kluczem jest to, ile ten klient jest skłonny zapłacić za tę możliwość wraz z bieżącym wsparciem? Jeśli pozwolisz im utworzyć niestandardowe pola na istniejącej tabeli i zdecydują, że chcą zmienić typ danych, który nie będzie płynnie konwertowany, czy oczekują od ciebie przetasowania i konwersji?

Możemy wynająć pełnoetatowego programistę za to, co płacimy za ten system. SalesForce.com i podobne witryny mają taką możliwość. Nie sądzę, że chcesz się z tym pogodzić w przypadku jednorazowej aplikacji klienckiej. Mogą równie dobrze zapłacić za aktualizację aplikacji w długim okresie.