2013-12-10 4 views
0

Для форума я хочу, чтобы пользователи могли отправлять сообщения друг другу. Для этого я создал таблицу под названием «Контакты». В этой таблице у меня 5 столбец: user_id, столбец для хранения друзей, один для хранения Family, один для хранения Business и один для других контактов. Эти последние четыре должны содержать массив, который содержит user_id этого типа контакта. Причина, по которой я выбрал этот дизайн, заключается в том, что я не хочу печатать слишком много или ограничивать пользователей количеством друзей, таких как friend1, friend2 и т. Д.Вставить массив в поле MYSQL

Мой вопрос: правильно ли это я делаю? ? Если нет, то что должно быть улучшено? И какой тип поля MYSQL должны быть друзьями, семьей, бизнесом и другими?

+0

читайте здесь http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php –

+6

Плохой дизайн. Вы никогда не храните несколько фрагментов данных в одном поле, если вам нужно получить доступ к этим отдельным битам как к отдельным. Хранение их всех в одном поле удаляет способность базы данных делать то, для чего она предназначена для: связывания данных. –

ответ

0

используйте serialize() и unserialize() функции.

Смотрите этот вопрос о том, как сохранить массив в MySQL: Save PHP array to MySQL?

Однако, это не рекомендуется, что вы делаете это. Я бы сделал отдельную таблицу, в которой хранятся все «соединения» между двумя пользователями. Например, если сказать, что Джон добавляет Али, будет запись, посвященная Али и Джону. Чтобы найти друзей пользователя, просто запросите записи, в которых есть Али или Джон. Но это мой личный способ делать что-то.

Я рекомендую вам запрашивать друзей пользователей, используя PHP/MySQL, все время, когда они вам нужны. Это может сэкономить значительное количество места и не займет столько времени.

1

Вместо этого вы должны иметь таблицу карт между вашей таблицей контактов и любыми связанными с ней таблицами (Пользователь, Друзья, Семья, Бизнес). Цель состояла бы в том, чтобы создать связь между вашим контактом и вашим пользователем и т. Д., Без необходимости делать то, о чем вы говорите, и использовать массивы, сжатые в поле varchar и т. Д.

Подход с структурированными данными дает вам более гибкое приложение.

E.g. В таблице UserContacts содержится собственный первичный ключ (id), внешний ключ для пользователей и внешний ключ для контактов. Вы делаете это для каждого типа, позволяя легко вставлять или изменять карты между любым количеством пользователей и контактами, когда захотите, без ущерба для других данных - и без сложной логики, чтобы разбить что-то вроде этого: 1,2,3,4,5 или 1|2|3|4|5:

id, user_id, contact_id 

Итак, когда вы приходите, чтобы использовать эту структуру, вы будете делать что-то вроде этого:

SELECT 
    Contacts.* 
    -- , Users.* -- if you want the user information 
FROM UserContacts 
LEFT JOIN Contacts ON (UserContacts.contact_id = Contacts.id) 
LEFT JOIN Users ON (Users.id = UserContacts.user_id) 
0

сериализуйте массив перед сохранением и несериализацией после извлечения.

$friends_for_db = serialize($friends_array); 
// store $friends_for_db into db 

И для извлечения:

// read $friends_for_db from db 
$friends_array = unserialize($friends_for_db); 

Однако, он должен быть мудрее следовать другие ответы о настройке соответствующего многие-ко-многим дизайн.

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

Смежные вопросы