Мне нужен совет по хранению данных в MySQL, где нужно хранить более одного, скажем, userids для одного поста?

Question

В тех случаях, когда кому-то нужно хранить более чем одно значение в ячейке, какой подход является более желательным и целесообразным, сохраняя его с разделителями или склеивая и разбирая его позже в массив для обработки на языке серверанапример, выбор.

$ returnFromDB = "159 | 160 | 161 | 162 | 163 | 164 | 165";$ myIdArray = explode ("|", $ returnFromDB);

или в виде сериализованного массива JSON или PHP, например:

: 6: {i: 0; i: 1; i: 1; i: 2; i: 2; i: 3; i: 3; i: 4; i: 4; i: 5; i: 5; i: 6;}

, а затем позднее его не сериализоватьв массив и работать с ним,

ИЛИ

иметь новую строку для каждой новой записи, как это

postid 12 |шоу 2постида 12 |шоу 3постида 12 |шоу 5постида 12 |шоу 6постида 12 |шоу 8

вместо постида 12 |showto "2 | 3 | 4 | 6 | 8 | 5 |".ИЛИ постид 12 |showto ": 6: {i: 0; i: 2; i: 1; i: 3; i: 2; i: 3; i: 3; i: 4; i: 4; i: 5; i: 5;я: 6;} ".

Спасибо, с нетерпением жду ваших мнений: D

Answer 1

В тех случаях, когда кому-то нужно хранить более чем одно значение в ячейке, какой подход является более желательным и целесообразным, сохраняя его с разделителями или склеивая и разбивая его позже в массив для обработки на языке сервера выбор, например.

Ни. О боже, нет! Эдгар Ф. Кодд катится в своей могиле прямо сейчас .

Хранить данные в текстовом поле с разделителями не лучше, чем хранить их в плоском файле . Данные становятся незапрашиваемыми. Хранение сериализованных данных PHP в текстовом поле еще хуже, потому что тогда только PHP может анализировать данные.

Вы хотите хорошую, счастливую, нормализованную базу данных .

То, что вы пытаетесь описать, это отношения многие ко многим. Каждый пользователь может поддерживать один или несколько сообщений. Кроме того, каждый пост может обслуживаться одним или несколькими пользователями. Правильно? Тогда что-то вроде этого будет работать.

CREATE TABLE users (
    user_id INTEGER PRIMARY KEY,
    ...
);

CREATE TABLE posts (
    post_id INTEGER PRIMARY KEY,
    ...
);
CREATE TABLE user_posts (
    user_id INTEGER REFERENCES users(user_id),
    post_id INTEGER REFERENCES posts(post_id),
    UNIQUE KEY(user_id, post_id)
);

-- All posts made by user 22.
SELECT posts.*
  FROM posts, user_posts
 WHERE user_posts.user_id = 22
   AND posts.post_id = user_posts.post_id

-- All users that worked on post 47
SELECT users.*
  FROM users, user_posts
 WHERE user_posts.post_id = 47
   AND users.user_id = user_posts.user_id

Answer 2

В большинстве случаев рекомендуется, чтобы отношения «многие ко многим» (например, публикации для пользователей) имели таблицу сопоставления с 1 строкой для каждой постпользовательской комбинации (другими словами, ваша «новая строка для каждой новой»). запись "версия).

Он более оптимален для таких вещей, как join запросы, и позволяет получать только те данные, которые вам нужны.

Answer 3

С точки зрения RDBMS, у меня будет «новая строка для каждой новой записи» Это называется таблицей отношений m: n. Затем вы можете запросить данные, как вам нравится.

Если вам нужно postid 12 | showto ":6:{i:0;i:2;i:1;i:3;i:2;i:3;i:3;i:4;i:4;i:5;i:5;i:6;}"., вы можете сделать

SELECT postid, CONCAT(':',count(showto),':{i:',GROUP_CONCAT(showto SEPARATOR ';i:'),';}') AS showto 
FROM tablename
GROUP BY postid

Однако если вам нужны только данные в форме 1 и вы не выполняете никаких других запросов к этим данным, вы можете также сохранить строку.

Answer 4

Вам следует сериализовать данные в БД только в том случае, если данные никогда не должны обрабатываться БД. Например, вы можете сериализовать идентификатор пользователя в поле user_id, если вам никогда не нужно делать запрос с полем user_id; например никогда не выбирайте что-либо на основе пользователя.

Если это сообщения (блог / новости / и т. Д.?), То я вполне уверен, что вам нужно будет запрашивать их у пользователя. Нормализация пользователя в другую таблицу послужит вам:

CREATE TABLE posts (post_id, ....);
CREATE TABLE post_users (post_id, user_id, ...);

Затем вы можете получить пользователей в другом запросе или использовать group_concat: SELECT post_id, GROUP_CONCAT(user_id) FROM posts JOIN post_users USING (post_id) GROUP BY post_id. Когда вам нужно показать имя пользователя, просто присоединитесь к таблице пользователей, чтобы получить их имя в группе concat.