Czy nie jest dobrym pomysłem posiadanie tabeli właściwości w bazie danych?

Question

Często, gdy potrzebuję przechowywać właściwości systemu, takie jak informacje o administratorze, wersje itp., Używam płaskiego pliku (database.properties, init.properties itd.). Wydaje się to powszechne w innych programach, które widzę i używam na co dzień.

Czasami płaski plik nie jest idealny z wielu powodów. Wdrażanie aplikacji internetowej dla wielu klientów często wiąże się z ograniczeniami. W takich przypadkach używam tabeli bazy danych do przechowywania informacji. Na przykład, powiedzmy, że mam dane administracyjne, które chcę zapisać, i być może pewne szczegóły dotyczące mojego środowiska. Mogę zrobić coś takiego:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT" 
2, 0, 1, "LICENCE", "88475", "INT" 
3, 0, 1, "TOP_PROJECT", "1", "INT" 
4, 0, 1, "SHOW_WELCOME", "F", "BOOL" 
5, 0, 1, "SMTP_AUTH", "SSH", "STRING" 
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL" 

Zdaję sobie sprawę, to przerywa pisanie SQL i pozwala mi do przechowywania różnego rodzaju typów jako ciągi. Czy to dobra praktyka, czy też źle to robiłem?

Jeśli nie, w jaki sposób powinienem przechowywać tego typu informacje?

Answer 1

Użyłem podobnej struktury do przechowywania danych nieruchomości i uważam, że jest w porządku, o ile tabela pozostanie stosunkowo mała. Tabela wartości atrybutu podmiotu (EAV) może zajmować więcej miejsca i cechuje się wolniejszą wydajnością kwerendy niż w przypadku tradycyjnej tabeli o strukturze kolumny, ale nie powinno to stanowić problemu dla zestawu właściwości aplikacji o rozsądnych rozmiarach.

Answer 2

Jest to przydatne w przypadku niewielkich ilości bardzo rzadko używanych danych.

Może się zdarzyć, że użytkownik, który patrzy na schemat, nie będzie widział poszczególnych właściwości aplikacji.

Ogranicza to problemy z aktualizacjami schematu. (Właściwości aplikacji są często dodawane/usuwane).

Nie nadaje się do dużych ilości danych lub danych, do których często się odwołują, ponieważ do pobrania danych potrzeba więcej pracy, a więcej miejsca zajmuje , niż w przypadku schematu konwencjonalnego.

Answer 3

Wydaje mi się, że jest to w porządku, ale warto rozważyć zapisanie danych w pamięci podczas czytania, aby nie musieć wracać do bazy danych. Jeśli przechowujesz dane w pamięci podręcznej, przechowuj je w dowolnym miejscu, w którym będzie to najprostsze. Zaletą przechowywania danych w bazie danych jest to, że łatwiej jest utrzymywać lub tworzyć interfejsy do zarządzania tymi właściwościami, szczególnie gdy zaczniesz używać rozproszonego środowiska dla twojej aplikacji.