Masz tutaj kilka pytań, więc odpowiem na nie osobno:
Muszę przechowywać kilka wybranych pozycji w jednym polu w bazie danych
Moja ogólna zasada brzmi:nie rób tego. To jest coś, co wymaga druga tabela (lub trzecia) z kluczem obcym. Jasne, teraz może się to wydawać łatwiejsze, ale co, jeśli pojawi się przypadek użycia, w którym musisz faktycznie zapytać o te elementy indywidualnie? Oznacza to również, że masz więcej opcji leniwego tworzenia instancji i masz bardziej spójne środowisko w wielu platformach/językach. Co więcej, jest mniej prawdopodobne, że będziesz mieć problemy z limitem czasu połączenia (30 000 znaków to dużo).
Wspomniałeś, że myślisz o użyciu ENUM. Czy te wartości są stałe? Czy znasz je z wyprzedzeniem? Jeśli tak, to byłaby moja struktura:
Tabela podstawowa (co masz teraz):
| id primary_key sequence
| -- other columns here.
Tabela przedmiotów:
| id primary_key sequence
| descript VARCHAR(30) UNIQUE
Tabela map:
| base_id bigint
| items_id bigint
Tabela map miałaby klucze obce, więc base_id mapuje do tabeli podstawowej, a items_id mapuje do tabeli elementów.
A jeśli chcesz w łatwy sposób pobrać to z bazy danych, utwórz widok, który wykonuje łączenia. Możesz nawet tworzyć reguły wstawiania i aktualizowania, dzięki czemu praktycznie masz do czynienia tylko z jedną tabelą.
Jakiego formatu powinienem używać do przechowywania danych?
Jeśli musisz zrobić coś takiego, dlaczego nie użyć po prostu ciągu znaków oddzielonego? Zajmie mniej mocy obliczeniowej niż CSV, XML lub JSON i będzie krótsze.
Jakiego typu kolumny powinienem użyć do przechowywania danych?
Osobiście użyłbym TEXT . Nie wygląda na to, że byś wiele zyskał, jeśli zmienisz to na BLOB i TEXT , z mojego doświadczenia wynika, że jest łatwiejszy do odczytania, jeśli używasz jakiejś formy IDE.
