Witam. Jestem w trakcie pisania pewnej aplikacji zarządzającej usługami serwerowymi i zastanawiam się nad użyciem pola TEXT do przechowywania konfiguracji parametrów serwera.

Sprawa wygląda tak:
- Mam tabelę z konfiguracją serwera, są tam dane dostępowe, hasła itd, tabela mniej więcej wygląda tak:
id | nazwa | login | hasło | ip | port | status

-Oprócz danych które są aktualnie przechowywane, potrzebuję też przechowywać parametry konfiguracji dla maszyny, które są bardzo rzadko edytowane i jeżeli są edytowane to całościowo, dodatkowo liczba tych parametrów wraz z rozbudową skryptu będzie wzrastać. Wspomniane dane konfiguracyjne mają być odczytywane wyłącznie takim zapytaniem:
select * from `maszyna` where `id` = :id limit 1
nie będzie wyszukiwania tych danych w mysqlu, ani sortowania

Myślę nad 3 opcjami:

1. Stworzenie pola TEXT, w którym przechowywana byłaby zserializowana tablica z danymi. To rozwiązanie jest dla mnie najwygodniejsze, ale tu rodzi się kilka pytań
-Czy przez to że jest to pole TEXT nie spadnie znacząco wydajność? Ponieważ skrypt bardzo często łączy się z maszynami i praktycznie cały czas te dane będą pobierane, a to pole text bedzie troche zajmowac bo zserializowane tablice zajmuja troche tekstu
-Czy funkcja unserialize nie będzie tu również problemem wydajnościowym?

2. Stworzenie pola VARCHAR(255), zapis danych poprzez implode('|', $dane), a odczyt przez explode('|', $dane) i operowanie na indeksach $dane[0], $dane[1] itd.
-Teoretycznie takie rozwiązanie zajmuje mniej miejsca w bazie i moze uzywac varchat, które chyba jest wydajniejsze
-Pytanie tylko czy explode() nie zabije tego rozwiązania wydajnościowo w porównaniu do poprzedniego rozwiązania?

3. Tworzenie dla każdego parametru oddzielnej kolumny varchar w tabeli `maszyna` i za kazdym razem przebudowa skryptu i bazy gdy dojdzie kolejny parametr konfiguracyjny (co chyba będzie wydajniejszym rozwiązaniem przy odczycie, ale totalną porażką przy rozbudowie)

Podsumowując:
Najbardziej odpowiada mi rozwiązanie nr. 1, ponieważ jest najwygodniejsze w rozbudowie i pozwala na pełną dowolność i strukturę przechowywanych danych, co może być dosyć przeydatne, tylko bardzo zastanawia mnie to czy pole TEXT i unserialize nie będzie znacznie wolniejsze niż np. rozwiązanie 3?

Trzecie rozwiązanie jest oczywiście złe i należy o nim zapomnieć.

Jeżeli całość danych można zmieścić w varchar(255) to nie ma znaczenie które rozwiązanie przyjmiesz. Przy tej skali problemu różnice będą niezauważalne.

1. Najpierw przeczytaj sobie jaka jest w ogóle różnica pomiędzy typem VARCHAR, a TEXT: https://www.google.com/search?q=mysql+varch...me&ie=UTF-8
2. Typ TEXT w żadnym wypadku nie jest złem.
3. Z jednej strony piszesz, o obawach związanych z nadmierną ilością danych, z drugiej rozważasz skorzystanie z VARCHAR(255) (VARCHAR może przechowywać do 65 tys. znaków).
4. (De)serializacja niemal na pewno będzie szybsza od explode/implode.
5. Jeżeli wiesz, że w danej tabeli znajduje się kolumna zawierająca potencjalnie sporo danych, nie powinieneś korzystać z SELECT *. Chyba, że rzeczywiście potrzebujesz wszystkich danych przy każdym zapytaniu.
6. Jeżeli rzeczywiście owa konfiguracja będzie Cię zawsze interesowała jedynie całościowo i nigdy nie będziesz chciał z poziomu bazy wykonywać na niej żadnych operacji poza odczytem i zapisem trzymanie jej w formie zserializowanej tablicy jest w porządku. W innym przypadku prawdopodobnie klasyczne rozwiązanie, tj. dodatkowa tabela z kolumnami SERVER_ID, PARAMETER, VALUE (pierwsze dwie kolumny jako klucz główny) będzie najwygodniejsze.