Korzystanie z jednorzędowej tabeli konfiguracji w bazie danych SQL Server. Kiepski pomysł?

Tworząc aplikację koszyka na zakupy stwierdziłem, że muszę zapisać ustawienia i konfiguracje w oparciu o preferencje i wymagania administratora. Mogą to być informacje o firmie, identyfikatory kont wysyłkowych, klucze API PayPal, preferencje powiadomień itp.

Tworzenie tabeli do przechowywania pojedynczego wiersza w systemie relacyjnej bazy danych wydaje się wysoce niewłaściwe.

Jaki jest właściwy sposób przechowywania tych informacji?

Uwaga: mój DBMS to SQL Server 2008, a warstwa programowania jest zaimplementowana w ASP.NET (w C #).

W przeszłości robiłem to na dwa sposoby - tabela z jednym wierszem i tabela par klucz / wartość - i każde podejście ma zalety i wady.

Jeden rząd

• dodatni: wartości są przechowywane we właściwym typie
• pozytywny: łatwiej poradzić sobie w kodzie (dzięki temu)
• pozytywne: wartości domyślne można nadać każdemu ustawieniu indywidualnie
• negatywne: aby dodać nowe ustawienie, wymagana jest zmiana schematu
• minus: stół może stać się bardzo szeroki, jeśli jest dużo ustawień

Para klucz / wartość

• pozytywne: dodanie nowych ustawień nie wymaga zmiany schematu
• pozytywne: schemat tabeli jest wąski, a dodatkowe wiersze są używane do nowych ustawień
• negatywne: każde ustawienie ma tę samą wartość domyślną (null / puste?)
• negatywne: wszystko musi być przechowywane jako ciągi (np. nvarchar)
• negatywne: kiedy masz do czynienia z ustawieniami w kodzie, musisz wiedzieć, jakiego typu jest ustawienie i rzucić je

Opcja pojedynczego rzędu jest zdecydowanie najłatwiejsza w użyciu. Dzieje się tak, ponieważ możesz przechowywać każde ustawienie w odpowiednim typie w bazie danych i nie musisz przechowywać typów ustawień, a także ich kluczy wyszukiwania w kodzie.

Jedną rzeczą, którą martwiłem się przy użyciu tego podejścia, było posiadanie wielu wierszy w „specjalnej” tabeli ustawień pojedynczego wiersza. Pokonałem to przez (w SQL Server):

• dodanie nowej kolumny bitowej z domyślną wartością 0
• tworzenie ograniczenia sprawdzającego, aby upewnić się, że ta kolumna ma wartość 0
• tworząc unikalne ograniczenie kolumny bitowej

Oznacza to, że w tabeli może istnieć tylko jeden wiersz, ponieważ kolumna bitowa musi mieć wartość 0, ale może istnieć tylko jeden wiersz z tą wartością ze względu na unikalne ograniczenie.

Powinieneś utworzyć tabelę z kolumną dla typu informacji i wartości informacji (przynajmniej). W ten sposób unikniesz konieczności tworzenia nowych kolumn za każdym razem, gdy dodawane są nowe informacje.

Pojedynczy rząd będzie działał dobrze; będzie miał nawet silne typy:

show_borders    bit
admin_name      varchar(50)
max_users       int

Jedną z wad jest to, że wymaga zmiany schematu ( alter table), aby dodać nowe ustawienie. Jedną z alternatyw jest normalizacja, w wyniku której otrzymujesz tabelę taką jak:

pref_name       varchar(50) primary key
pref_value      varchar(50) 

Ma słabe typy (wszystko jest varchar), ale dodanie nowego ustawienia jest po prostu dodaniem wiersza, co można zrobić tylko z dostępem do zapisu w bazie danych.

Osobiście zapisałbym go w jednym rzędzie, jeśli to działa. Przesadne przechowywanie go w tabeli SQL? prawdopodobnie, ale nie ma w tym żadnej szkody.

Jak się domyślacie, z wyjątkiem najprostszych sytuacji, umieszczenie wszystkich parametrów konfiguracji w jednym wierszu ma wiele wad. To zły pomysł ...

Wygodnym sposobem przechowywania informacji o konfiguracji i / lub preferencjach użytkownika jest format XML . Wiele DBMS obsługuje typ danych XML. Składnia XML umożliwia wykorzystanie „języka” i struktury opisującej konfigurację w miarę jej rozwoju. Jedną z zalet XML jest niejawna obsługa struktury hierarchicznej, co pozwala na przykład na przechowywanie małych list parametrów konfiguracyjnych bez konieczności nadawania im nazwy przyrostka z numerem. Możliwą wadą formatu XML jest to, że wyszukiwanie i ogólnie modyfikowanie tych danych nie jest tak proste, jak inne podejścia (nic skomplikowanego, ale nie tak proste / naturalne)

Jeśli chcesz pozostać bliżej modelu relacyjnego , prawdopodobnie potrzebujesz modelu Entity-Attribute-Value , w którym poszczególne wartości są przechowywane w tabeli, która zwykle wygląda następująco:

EntityId     (foreign key to the "owner" of this attribute)
AttributeId  (foreign key to the "metadata" table where the attribute is defined)
StringValue  (it is often convenient to have different columns of different types
IntValue      allowing to store the various attributes in a format that befits 
              them)

Gdzie AttributeId jest kluczem obcym do tabeli, w której zdefiniowany jest każdy możliwy atrybut ("parametr konfiguracyjny" w twoim przypadku), powiedzmy

AttributeId  (Primary Key)
Name
AttributeType     (some code  S = string, I = Int etc.)
Required          (some boolean indicating that this is required)
Some_other_fields   (for example to define in which order these attributes get displayed etc...)

Wreszcie EntityId pozwala zidentyfikować jakąś jednostkę, która „posiada” te różne atrybuty. W twoim przypadku może to być identyfikator użytkownika lub nawet niejawny, jeśli masz tylko jedną konfigurację do zarządzania.

Oprócz umożliwienia powiększania listy możliwych parametrów konfiguracyjnych wraz z rozwojem aplikacji, model EAV umieszcza „metadane”, tj. Dane odnoszące się do samego Atrybutu, w plikach danych, unikając w ten sposób całego kodowania nazw kolumn, które są powszechnie spotykane gdy parametry konfiguracyjne są przechowywane w jednym wierszu.

Z pewnością nie musisz zmieniać schematu podczas dodawania nowego parametru konfiguracji w znormalizowanym podejściu, ale prawdopodobnie nadal zmieniasz kod, aby przetworzyć nową wartość.

Dodanie „tabeli zmian” do wdrożenia nie wydaje się być tak dużym kompromisem dla prostoty i bezpieczeństwa typu podejścia opartego na jednym wierszu.

Para klucz i wartość jest podobna do .Net App.Config, która może przechowywać ustawienia konfiguracji.

Więc jeśli chcesz pobrać wartość, którą możesz zrobić:

SELECT value FROM configurationTable
WHERE ApplicationGroup = 'myappgroup'
AND keyDescription = 'myKey';

Typowym sposobem na to jest posiadanie tabeli „właściwości”, która jest identyczna z plikiem właściwości. Tutaj możesz przechowywać wszystkie stałe aplikacji lub nie tak stałe rzeczy, które po prostu musisz mieć pod ręką.

Następnie możesz pobrać informacje z tej tabeli, gdy ich potrzebujesz. Podobnie, gdy stwierdzisz, że masz inne ustawienia do zapisania, możesz je dodać. Oto przykład:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "COMPANY_INFO", "Acme Tools", "ADMIN"  
2, 0, 1, "SHIPPING_ID", "12333484", "ADMIN"  
3, 0, 1, "PAYPAL_KEY", "2143123412341", "ADMIN"   
4, 0, 1, "PAYPAL_KEY", "123412341234123", "ADMIN"  
5, 0, 1, "NOTIF_PREF", "ON", "ADMIN"  
6, 0, 2, "NOTIF_PREF", "OFF", "ADMIN"   

W ten sposób możesz przechowywać dane, które posiadasz oraz dane, które będziesz mieć w przyszłym roku, o których jeszcze nie wiesz :).

W tym przykładzie twój zakres i refId mogą być używane do wszystkiego, co chcesz na zapleczu. Więc jeśli propertyType „ADMIN” ma zakres 0 refId 2, wiesz, jakie to preferencje.

Typ nieruchomości przydaje się, gdy pewnego dnia będziesz musiał przechowywać tutaj również informacje niebędące administratorami.

Pamiętaj, że nie powinieneś przechowywać danych koszyka w ten sposób ani wyszukiwać w tej sprawie. Jeśli jednak dane są specyficzne dla systemu , z pewnością możesz użyć tej metody.

Na przykład: jeśli chcesz przechowywać swoją DATABASE_VERSION , użyłbyś takiej tabeli. W ten sposób, gdy musisz zaktualizować aplikację, możesz sprawdzić tabelę właściwości, aby zobaczyć, jaką wersję oprogramowania ma klient.

Chodzi o to, że nie chcesz tego używać do rzeczy, które dotyczą koszyka. Utrzymuj logikę biznesową w dobrze zdefiniowanych tabelach relacyjnych. Tabela właściwości służy tylko do informacji systemowych.

Nie jestem pewien, czy pojedynczy wiersz jest najlepszą implementacją do konfiguracji. Lepiej byłoby mieć wiersz na element konfiguracji z dwiema kolumnami (configName, configValue), chociaż będzie to wymagało rzutowania wszystkich wartości na ciągi i z powrotem.

Niezależnie od tego nie ma nic złego w używaniu jednego wiersza do konfiguracji globalnej. Inne opcje przechowywania go w bazie danych (zmienne globalne) są gorsze. Możesz to kontrolować, wstawiając pierwszy wiersz konfiguracji, a następnie wyłączając wstawianie w tabeli, aby zapobiec tworzeniu wielu wierszy.

Możesz wykonać parę klucz / wartość bez konwersji, dodając kolumnę dla każdego głównego typu i jedną kolumnę informującą, w której kolumnie znajdują się dane.

Twój stół wyglądałby więc mniej więcej tak:

id, column_num, property_name, intValue, floatValue, charValue, dateValue
1, 1, weeks, 51, , ,
2, 2, pi, , 3.14159, , 
3, 4, FiscYearEnd, , , , 1/31/2015
4, 3, CompanyName, , , ACME, 

Zajmuje trochę więcej miejsca, ale co najwyżej używasz kilkudziesięciu atrybutów. Możesz użyć instrukcji case poza wartością column_num, aby wyciągnąć / dołączyć do odpowiedniego pola.

Przepraszam, że przyszedłem, tak później. Ale w każdym razie to, co robię, jest proste i skuteczne. Po prostu tworzę tabelę z trzema () kolumnami:

ID - int (11)

nazwa - varchar (64)

wartość - tekst

To, co robię przed utworzeniem nowej kolumny konfiguracyjnej, aktualizacją lub odczytem, ​​to serializowanie „wartości”! W ten sposób jestem pewien typu (cóż, php jest :))

Na przykład:

b: 0; jest dla B OOLEAN ( fałsz )

b: 1; jest dla B OOLEAN ( prawda )

i: 1988; jest dla I NT

s: 5: "Kader"; dotyczy S TRINGU o długości 5 znaków

Mam nadzieję, że to pomoże :)

Miej kolumnę kluczową jako varchar i kolumnę wartości jako JSON. 1jest numeryczne, podczas gdy "1"jest łańcuchem. truei falseoba są logiczne. Możesz też mieć przedmioty.