Najlepszy sposób przechowywania danych "ustawień witryny" w tabeli bazy danych?

Question

Pracuję na rynku i zastanawiałem się, jaki jest najlepszy sposób obsługi ustawień witryny, takich jak tytuł, adres URL, czy jego https, kontaktowy adres e-mail, wersja, itp.

Próbuję struktury tabeli tak można go łatwo zaktualizować i dodać do niego więcej ustawień w celu pobrania.

Opracowałem 2 struktury, albo zachowaj je w jednym wierszu, z nazwami kolumn jako nazwą ustawienia, a kolumną wartości wiersza jako wartością ustawienia. i po prostu echo nazwy kolumny pierwszego wiersza z mysql_fetch_assoc.

Myślałem także o nowym rzędzie automatycznego przyrostu dla każdego ustawienia. I przekształcenie go w tablicę, aby pobrać z bazy danych, aby przypisać nazwę kolumny dla kolumny, pobierając nazwę ustawienia.

Jaki byłby twój sposób na efektywne radzenie sobie z tym problemem. Dziękuję Ci.

Answer 1

Dwa sposoby działają dobrze. Powiedziałbym, że jeśli chcesz zarządzać tymi ustawieniami w panelu administracyjnym, ustawienie jedno po drugim jest lepsze, ponieważ możesz dodać nowe ustawienia w locie za pomocą prostego zapytania INSERT od administratora. Co jest lepsze (bardziej bezpieczne) niż zapytanie ALTER TABLE.

Answer 2

Wiersz dla każdego odrębnego ustawienia opcji, przy użyciu par nazwa/wartość po jednym w wierszu, jest prawdopodobnie najlepszym sposobem. Jest bardziej elastyczny niż wiele kolumn; jeśli dodasz ustawienie opcji, nie będziesz musiał wykonywać żadnej operacji ALTER TABLE.

Tabela wp_options WordPress działa w ten sposób. Spójrz tutaj. http://codex.wordpress.org/Options_API

Jeśli masz opcję "złożoną", możesz serialize tablicę php do przechowywania go w jednym wierszu tabeli.

Answer 3

To zależy od technologii, z której korzystasz. Na przykład w PHP Symfony Project ustawienia są przechowywane głównie w plikach płaskich (Json, xml ...).

Pracowałem przy wielu dużych aplikacjach internetowych dla klientów. Tabela kluczy/wartości jest powszechnie używana do przechowywania prostych ustawień. Jeśli chcesz przechowywać więcej niż jedną wartość, musisz serializować je, więc jest to trochę trudne.

Należy pamiętać o szyfrowaniu poufnych danych, takich jak hasła (Sha256 + sól).

Najlepszym sposobem jest utworzenie dwóch tabel. tabelę do przechowywania ustawień jako klucz/wartość:

CREATE TABLE Settings (
    Id INT NOT NULL PRIMARY KEY, 
    Key NOT NULL NVARCHAR, 
    Value NULL NVARCHAR 
    EnvId INT NOT NULL 
); 

Następnie trzeba tabelę Środowisko.

CREATE TABLE Environment (
    Id INT NOT NULL PRIMARY KEY, 
    Key NOT NULL NVARCHAR, 
); 

Nie zapomnij o ograniczeniu klucza obcego.

Ponadto należy utworzyć te tabele w oddzielnym schemacie. Będziesz mógł zastosować politykę bezpieczeństwa, filtrując dostęp.

Abyś mógł pracować w wielu środowiskach (dev, test, produkcja, ...) wystarczy aktywować jedno środowisko. Można na przykład skonfigurować, aby nie wysyłać wiadomości e-mail w środowisku programistycznym, ale wysłać je w środowisku produkcyjnym.

Wykonuje się łączenie w celu uzyskania ustawień dla określonego środowiska. Możesz dodać wartość logiczną, aby łatwo przełączać się między środowiskami.

Jeśli korzystasz z pliku (nie potrzeba połączenia dB) można dostać coś takiego (Json):

Env: 
    Dev: 
     Email: ~ 
    Prod: 
     Email: contact@superwebsite.com 

Answer 4

Przede wszystkim chciałbym considere jeszcze jedno, plik konfiguracyjny .. .

Następnie należy zadać sobie pytanie, co trzeba dla swojego projektu ...

Przede wszystkim chciałbym considere plik konfiguracyjny vs bazy danych:

Dużą zaletą opcji baz danych w pliku konfiguracyjnym to skalowalność, jeśli masz wiele aplikacji/witryn, które wymagają tych konfiguracji, to przejdź do bazy danych, ponieważ pozwoliłoby ci to na kopiowanie kilkukrotnie tego samego pliku konfiguracyjnego ze wszystkimi problemami związanymi z wersją i modyfikacją pliku na wszystkich "różnych" stronach "

W przeciwnym razie trzymałbym się pliku konfiguracyjnego, ponieważ dostęp jest szybszy dla aplikacji, a plik może nadal być dostępny w przypadku przerwy w działaniu serwera sql, w którym to przypadku niektóre konfiguracje wciąż mogą być odpowiednie, plik konfiguracyjny może być również dołączony przez twoje oprogramowanie do wersjonowania. Ze względów bezpieczeństwa, wyobraź sobie, że twój DB jest współdzielony przez wiele programów ...

Jeśli więc trzymasz się bazy danych, poleciłbym jedną etykietę z jednym wierszem i uważam, że łatwiej zarządzać dokumentacją niż strukturą tabeli, specjalnie w miarę upływu czasu i ewolucji twojego oprogramowania. Jeśli inny deweloper dołączy do twojego projektu, twoja struktura tabeli może szybko stać się wielkim bałaganem:]

Ostatnim argumentem jest bezpieczeństwo ... Dobrą praktyką jest ustawienie "użytkownika DB" tworzyć oprogramowanie dla użytkownika, który nie ma uprawnień do modyfikacji struktury DB, a jedynie prawo dostępu/usuwania rekordów usuwania;)