столбец JSON против нескольких столбцов

Question

я даже не знаю, правильно ли это назвать сериализованный столбец , но я собираюсь объяснить, например, у меня есть таблица для пользователей, я хочу сохранить телефонные номера пользователей (мобильный телефон, дом, офис и т. д.), поэтому я подумал создать столбец для каждого типа чисел, но в то же время мне пришла в голову мысль, что если я сохраню строку json в одном столбце Таким образом, у меня никогда не будет столбца, который, вероятно, никогда не будет использоваться, и я могу превратить эту строку в массив php при чтении данных из базы данных, но я хотел бы услышать о плюсах и минусах этой практики, возможно, это просто плохая идея, но сначала я хочу узнать, что другие люди говорят о

спасибо

Answer 1

Короткий ответ, несколько столбцов.

Длинный ответ:

Ради любви ко всему святому в мире, пожалуйста, не храните множественные наборы данных в одном текстовом столбце

Я предполагаю, что у вас будет таблица, которая будет либо

+------------------------------+      +----------------------+
| User |  cell | office | home |  OR  | User | JSON String   |
+------------------------------+      +----------------------+

Сначала я скажу, что оба эти решения не являются лучшим решением, но если вы выберете одно из двух, первое будет лучшим. Есть несколько причин, в основном, хотя возможность модифицировать и выполнять конкретные запросы действительно важна. Подумайте о algrothim, чтобы изменить второй вариант.

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

Это решение включает в себя 2 запроса и алгоритм поиска и замены. Нет, хорошо!

Теперь подумайте о первом решении.

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` = ?

Это явно лучше, но не лучше

Существует третье решение. Предположим, вы хотите, чтобы пользователь мог вводить бесконечное количество телефонных номеров.

Позволяет использовать для этого таблицу отношений, так что теперь у вас есть две таблицы.

              +-------------------------------------+
+---------+   |      Phone                          | 
| Users   |   +-------------------------------------+ 
+---------+   | user_name| phone_number | type      |
| U_name  |   +-------------------------------------+
+---------+

Теперь вы можете запросить все телефонные номера пользователя примерно так

Теперь вы можете запросить таблицу через объединение

ВЫБРАТЬ пользователей. , телефон. ИЗ телефона, пользователей ГДЕ phone.user_name =? AND Users.U_name =?

Вставки также просты, а проверка типов также проста.

Помните, что это простой пример, но SQL действительно предоставляет массу возможностей вашей структуре данных, вы должны использовать ее, а не избегать ее

Answer 2

Если вы работаете с json, есть более элегантные способы, чем MySQL. Рекомендую использовать другую базу данных, которая лучше работает с json, например mongoDB, или оболочку для SQL, например Persevere, http://www.persvr.org/Documentation (см. «Сохранение»)

Answer 3

Я бы делал это только с несущественными данными, например, с любимым цветом пользователя, любимым типом сумчатого (очевидно, «несущественное» - решать вам). Проблема с выполнением этого для важных данных (номер телефона, имя пользователя, адрес электронной почты, имя, фамилия и т. Д.) Заключается в том, что вы ограничиваете себя тем, что вы можете сделать с базой данных. К ним относятся поля индексации, использование предложений ORDER BY или даже поиск определенного фрагмента данных. Если позже вы поймете, что вам нужно выполнить какое-либо из этих заданий, это станет большой головной болью.

Лучшее в этой ситуации - использование реляционной таблицы от 1 до многих объектов - например, UserPhoneNumbers. Он будет иметь 3 столбца: user_id, phone_number и type. user_id позволяет связать строки в этой таблице с соответствующей строкой таблицы User, phone_number говорит само за себя, а type может быть 'home', 'cell', 'office' и т. Д. Это позволяет вам по-прежнему выполнять задачи, о которых я упоминал выше, а также имеет дополнительное преимущество, заключающееся в том, что вы не тратите пространство на пустые столбцы, поскольку вы добавляете строки в эту таблицу только по мере необходимости.

Я не знаю, насколько вы знакомы с MySQL, но если вы еще не слышали о нормализации базы данных и запросах JOIN, сейчас самое время начать их читать:)

Надеюсь, это поможет.

Answer 4

Я не уверен, каковы будут преимущества этого подхода. Вы говорите: «Так, у меня никогда не будет столбца, который, вероятно, никогда не будет использоваться ...». Я думаю, вы имели в виду (в вашей системе), что иногда у пользователя может не быть значения для каждого типа телефонного номера, и в таком случае зачем хранить записи с пустыми столбцами?

Хранение записей с некоторыми пустыми столбцами не обязательно плохо. Однако, если вы хотите нормализовать базу данных, вы можете иметь отдельную таблицу для user_phonenumber и создать отношение 1: много между user и user_phonenumber записями. Таблица user_phonenumber будет иметь четыре столбца:

• id (первичный ключ)
• ИД пользователя (внешний ключ к пользовательской таблице)
• тип (например, мобильный телефон, дом, офис и т. Д.)
• значение (номер телефона)

Ограничения будут заключаться в том, что id является первичным ключом, userid является внешним ключом для user.id, а type будет перечислением (всех возможных типов телефонных номеров).