Kort svar, flere kolonner.
Langt svar:
Af kærlighed til alt, hvad der er helligt i verden, skal du ikke gemme flere datasæt i en enkelt tekstkolonne
Jeg går ud fra, at du vil have et bord, der enten vil være
+------------------------------+ +----------------------+
| User | cell | office | home | OR | User | JSON String |
+------------------------------+ +----------------------+
Først vil jeg sige, at begge disse løsninger ikke er den bedste løsning, men hvis du skulle vælge den fra de to, er den første bedst. Der er et par grunde, primært selvom evnen til at ændre og forespørge specifikt er virkelig vigtig. Tænk på algrothim for at ændre den anden mulighed.
SELECT `JSON` FROM `table` WHERE `User` = ?
Then you have to do a search and replace in either your server side or client side language
Finally you have to reinsert the JSON string
Denne løsning består af i alt 2 forespørgsler og en søg og erstat-algoritme. Ikke godt!
Tænk nu på den første løsning.
SELECT * FROM `table` WHERE `User` = ?
Then you can do a simple JSON encode to send it down
To modify you only need one Query.
UPDATE `table` SET `cell` = ? WHERE `User` = ?
to update more than one its again a simple single query
UPDATE `table` SET `cell` = ?, `home` = ? WHERE `User` = ?
Dette er klart bedre, men det er ikke bedst
Der er en tredje løsning Lad os sige, at du ønsker, at en bruger skal kunne indsætte et uendeligt antal telefonnumre.
Lad os bruge en relationstabel til det, så nu har du to tabeller.
+-------------------------------------+
+---------+ | Phone |
| Users | +-------------------------------------+
+---------+ | user_name| phone_number | type |
| U_name | +-------------------------------------+
+---------+
Nu kan du forespørge alle telefonnumre på en bruger med sådan noget
Nu kan du forespørge i tabellen via en join
VÆLG brugere., telefon. FRA Phone, Users WHERE phone.user_name =? OG Users.U_name =?
Indstik er lige så nemme, og typekontrol er også nemt.
Husk, at dette er et simpelt eksempel, men SQL giver virkelig et væld af kraft til din datastruktur, du bør bruge det i stedet for at undgå det.