Po pierwsze, naprawdę nie chcesz tego robić. Kolumna w RDBMS ma być niepodzielna, ponieważ zawiera jedną i tylko jedną informację. Próba przechowywania więcej niż jednego fragmentu danych w kolumnie jest naruszeniem pierwszej normalnej postaci.
Jeśli koniecznie musisz to zrobić, musisz przekonwertować dane do postaci, która może być przechowywana jako pojedynczy element danych, zwykle ciąg. Możesz użyć mechanizmu serialize() PHP, parsowania XML (jeśli dane są drzewem dokumentów), json_encode() itp.
Ale jak skutecznie przeszukiwać takie dane? Odpowiedź brzmi:nie możesz.
Ponadto, jeśli ktoś inny przejmie Twój projekt w późniejszym terminie, naprawdę go zdenerwujesz, ponieważ zserializowane dane w bazie danych są okropne w pracy. Wiem, bo takie projekty odziedziczyłam.
Czy wspomniałem, że naprawdę nie chcesz tego robić? Musisz przemyśleć swój projekt, aby łatwiej było go przechowywać w postaci rzędów atomowych. Użyj na przykład innej tabeli dla tych danych i użyj kluczy obcych, aby powiązać je z rekordem głównym. Nie bez powodu nazywane są relacyjnymi bazami danych.
AKTUALIZUJ :Zapytano mnie o wymagania dotyczące przechowywania danych, na przykład o to, czy pojedynczy wiersz byłby tańszy pod względem przechowywania. Odpowiedź brzmi, w typowych przypadkach nie, nie jest, a w przypadkach, gdy odpowiedź brzmi tak, cena, jaką za to płacisz, nie jest warta płacenia.
Jeśli użyjesz tabeli zależnej od 2 kolumn (1 kolumna dla klucza obcego rekordu, do którego należy próbka, jedna dla pojedynczej próbki), wtedy każda kolumna będzie wymagała w najgorszym przypadku 16 bajtów (8 bajtów dla kolumny klucza longint, 8 bajtów dla liczby zmiennoprzecinkowej podwójnej precyzji). Dla 100 rekordów to 1600 bajtów (ignorując obciążenie bazy danych).
W przypadku ciągu serializowanego przechowujesz w najlepszym przypadku 1 bajt na znak w ciągu. Nie możesz wiedzieć, jak długi będzie ciąg, ale jeśli przyjmiemy 100 próbek ze wszystkimi przechowywanymi danymi przez jakiś wymyślony zbieg okoliczności, wszystkie mieszczące się w przedziale od 10000,00 do 99999,99, przy czym zawsze będą tylko 2 cyfry po przecinku, to wtedy... przyglądając się 8 bajtom na próbkę. W tym przypadku wszystko, co zapisałeś, to obciążenie kluczy obcych, więc wymagana ilość pamięci wynosi 800 bajtów.
To oczywiście opiera się na wielu założeniach, takich jak kodowanie znaków zawsze o długości 1 bajtu na znak, ciągi tworzące próbki nigdy nie są dłuższe niż 8 znaków itp.
Ale oczywiście istnieje również narzut jakiegokolwiek mechanizmu używanego do serializacji danych. Absolutnie najprostsza metoda, CSV, polega na dodaniu przecinka między każdą próbką. To dodaje n-1 bajtów do przechowywanego ciągu. Więc powyższy przykład miałby teraz 899 bajtów, i to z najprostszym schematem kodowania. JSON, XML, a nawet serializacje PHP dodają więcej dodatkowych znaków niż to, a wkrótce będziesz miał ciągi, które są znacznie dłuższe niż 1600 bajtów. A wszystko to przy założeniu 1-bajtowego kodowania znaków.
Jeśli musisz zindeksować próbki, wymagania dotyczące danych wzrosną jeszcze bardziej nieproporcjonalnie w stosunku do ciągów, ponieważ indeks ciągu jest znacznie droższy pod względem przechowywania niż byłby indeks kolumny zmiennoprzecinkowej.
I oczywiście, jeśli twoje próbki zaczną dodawać więcej cyfr, pamięć danych rośnie dalej. 39281.3392810 nie będzie przechowywany w 8 bajtach jako ciąg, nawet w najlepszym przypadku.
A jeśli dane są serializowane, baza danych nie może manipulować. Nie możesz sortować próbek, wykonywać na nich żadnych operacji matematycznych, baza danych nawet nie wie, że to liczby!
Szczerze mówiąc, pamięć masowa jest obecnie śmiesznie tania, możesz kupić wiele dysków TB za niewielkie sumy. Czy przechowywanie jest naprawdę takie krytyczne? Chyba że masz setki milionów płyt, to wątpię.
Możesz zapoznać się z książką o nazwie Antywzorce SQL
