Каков правильный способ хранения этих данных в схеме MySQL?

Question

У меня есть movie в базе данных MySQL. movie содержит атрибуты данных, которые никогда не изменятся, такие как:

• Штрих-код: 025192018626
• Формат: DVD
• Продолжительность: 121 мин.
• Диски: 1
• Название: 12 Monkeys
• Год выпуска: 1995

Это одна строка в таблице.

Но Я хочу дать полную информацию о моей пользователе в отношении этой информации в случае, если что-то не соответствует им или если они просто хотят изменить способ отображения данных каким-либо образом. Меня не волнует, почему, я просто хочу дать своим пользователям возможность делать то, что они хотят.

Предположим, что пользователь # 1 хочет изменить заголовок, чтобы он был «12 обезьян (полка 1)», и это все, что они меняют.

И, скажем, пользователь # 2 хочет вместо этого заменить DVD на цифровую копию.

И, скажем, пользователь №3 хочет изменить заголовок, чтобы они были «Двенадцать обезьян», потому что это альтернативный заголовок.

т.д.

Мой вопрос, как я могу хранить только что одно изменение в этом одно поле только для этого пользователя, не изменяя исходные данные? В отдельной идентичной таблице со всеми полями указаны одни и те же данные, за исключением того, что один поле? Или я могу просто сохранить одно единственное изменение (например, название) и вернуться к данным movie для остальных?

Каков правильный способ его разработки, особенно если у меня есть 1000 пользователей, которые вносят изменения в пользовательские данные в основном на одно или два поля?

Answer 1

Вместо одной строки для каждого фильма используйте таблицу значений атрибута. Затем добавьте к нему дополнительное поле, которое указывает пользователя, который будет 0 для первоначального значения по умолчанию.Таким образом, таблица выглядит следующим образом:

MovieID UserID Attribute Value 
1  0  Title  12 Monkeys 
1  0  Format  DVD 
1  1  Title  Twelve Monkeys 

Тогда запрос, чтобы получить титул будет выглядеть так:

SELECT MovieID, IFNULL(my.Value, default.Value) AS title 
FROM movies AS default 
LEFT JOIN movies AS my ON default.MovieID = my.MovieID AND my.Attribute = 'Title' AND my.userID = @user 
WHERE default.UserID = 0 AND default.Attribute = 'Title' 

Некоторые разработчики баз данных также хотели бы использовать AttributeID вместо строки в качестве имени атрибута, и отдельную таблицу, которая сопоставляет имена атрибутов идентификаторам.

Answer 2

Моя первая мысль: зачем вам это нужно?

Моя вторая мысль иметь customizations стол что-то вроде

+--------+---------+-------------+------------+ 
| userid | barcode | column_name | custom_val | 
+--------+---------+-------------+------------+ 

тогда, когда пользователь запрашивает систему, искать их идентификатор пользователя и column_name в customizations таблице, чтобы найти альтернативное значение дисплея.

Это позволит пользователю заменить одно значение в одной строке. Заменить одно значение во всех строках, где оно существует, было бы гораздо более сложным предложением.

Answer 3

Я предлагаю, что нет «правильного» способа. Но вам может понравиться это ...

• Ваш Movie стол остается как есть. (Я предполагаю, что есть id.)
• Другая таблица, UserMovie с теми же колоннами, за исключением:
  • Все столбцы, кроме id являются NULL
  • Он имеет еще один столбец: user NOT NULL
  • PRIMARY KEY(id, user)

Когда пользователь что-то изменяет, используйте INSERT INTO UserMovie .. ON DUPLICATE KEY UPDATE .. изменить любое поле (и), которое он хочет установить. Обратите внимание, что IODKU будет INSERT новой строки, если она не существует, или UPDATE существующей строки (поскольку пользователь модифицирует другой столбец). Например, чтобы переопределить только "название" для ид = $ ID,

INSERT INTO UserMovie 
    (id, title) 
    VALUES 
    ($id, '$title') 
ON DUPLICATE KEY UPDATE 
    title = '$title'; 

Когда пользователь хочет увидеть, что у него есть,

SELECT coalesce(u.title, m.title) AS title, 
     coalesce(u.format, m.format) AS format, 
     coalesce... 
    FROM Movie AS m 
    LEFT JOIN UserMovie AS u 
      ON u.id = m.id 
      AND u.user = $user 
    WHERE m.id = $id; 

В COALESCE тихо Pics либо u.xxx если NOT NULL, или m.xxx.

Эта конструкция имеет то преимущество, что она очень компактна. (NULLs почти не занимают места.)

Если пользователь дважды меняет «заголовок», сохраняется только последняя версия.

Чтобы «вернуть» название:

UPDATE UserMovie SET title = NULL 
    WHERE id = $id 
     AND user = $user; 

(Конечно, это может оставить ряд всех NULLs, но остальная часть кода все еще работает.)

Answer 4

Хороший дизайн не является совершенным для всех ситуаций. Однако есть идеальный дизайн для ситуации.

Задайте себе вопрос: 1) какова цель этого проекта и 2) как вы собираетесь извлекать данные из проекта.

По вашему вопросу, если фильм не изменяет его атрибуты, плоская таблица однорядная идеально:

table: movie 
id | barcode  | format_id | runtime | disc | year_made | title 
---+--------------+-----------+---------+------+-----------+----------- 
1 | 025192018626 | 1   | 121  | 1 | 1995  | 12 Monkeys 

И вам может понадобиться внешняя таблица movie_format

table: movie_format 
id | format 
---+------- 
1 | DVD 

Над дизайном очень быстро подходит для поиска.

Теперь вы хотите сохранить все изменения или другую информацию, но не уверены в том, что это такое. В этом случае мета-таблица более подходит. Meta таблица, как правило, идеально подходит, если вам нужно только для отображения в соответствии с первичным ключом (фильм) и не используется для поиска:

table: movie_meta 
id | movie_id | user_id | created    | meta  | info 
---+----------+---------+---------------------+-----------+--------- 
1 | 1  | 123  | 2016-01-28 11:22:33 | format_id | 2 
2 | 1  | 456  | 2016-01-28 11:55:33 | disc  | 3 
5 | 1  | 666  | 2016-07-14 12:58:55 | title  | 十二头傻猴子 

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