mysql - дизайн стола для системы встраивания

Question

Я работаю над разделом для встраивания на моем сайте, где пользователи могут вставлять различные медиа из различных сервисов, YouTube, MySpace Music, Vimeo и т. Д.

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

Изначально я думал, что у меня есть таблица со строкой для каждого вложенного элемента, например:

• embedid (первичный ключ с автоинкрементом),
  ИД пользователя, внедренный_элемент (например, идентификатор YouTube)

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

• userid, youtubeid, vimeoid,
  myspaceid1, myspaceid2

но это кажется немного неуклюжим, особенно если учесть, что всегда будут пустые строки, поскольку пользователи не могут иметь их все. У кого-нибудь есть лучшее решение?

Answer 1

• В таблице `EmbededItem 'есть столбцы, общие для всех элементов.
• YouTube, Vimeo, MySpace имеют только столбцы, специфичные для каждого.
  
  

Answer 2

Итак, вот что я бы сделал в такой ситуации: Настройте свою таблицу со столбцами для полей первичного ключа и идентификатора пользователя, а также всего, что вам может понадобиться для идентификации пользователя или приложения (возможно, поля «mediatype»). Остальные, помещенные в поле VARCHAR, делают его достаточно большим для хранения большого количества данных. Не уверен, сколько места вам понадобится, но я рискну предположить, что вам понадобится от 1 до 4 тысяч места.

Причина поля VARCHAR: вы никогда не знаете, какие другие новые поля вам понадобятся в будущем. Допустим, в следующем году YouTube добавит еще один параметр или появится новый формат мультимедиа. Если вы смоделируете свою базу данных для представления всех полей по отдельности, вы создадите приложение, которое не масштабируется для будущих или других форматов мультимедиа. Такое моделирование прекрасно, когда вы описываете систему на бумаге, но не так хорошо, когда вы реализуете код.

Итак, теперь, когда у вас есть поле varchar для хранения всех ваших данных, у вас есть несколько вариантов того, как хранить данные:

1. Вы можете хранить данные в виде XML-документа и анализировать их при вводе / выводе (но вам, скорее всего, потребуется более 4 КБ места), и вы будете нести расходы на анализ XML.

2. Вы можете хранить данные в любом формате, который вам может понадобиться для вашего приложения (сериализованный объект для Java, JSON для JavaScript и т. Д.). Если вы сериализуете объект, вам также может потребоваться более 4 КБ пространства и поле VARBINARY, а не VARCHAR.

3. строка с разделителями-запятыми, хотя это не работает, если ваши строки содержат запятые. Я, вероятно, не рекомендовал бы это.

4. Строки пары ключ / значение, разделенные нулем, с двойным нулем в конце. Для этого вам потребуется поле данных VARBINARY.

Номер 4 - мой любимый, и я бы порекомендовал. Я использовал этот шаблон для существующего веб-проекта, где мои строки хранятся в формате:

'uid=userid/0var1=value1/0val2=value2/0url=urltosite/0/0'

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

Ваше приложение может использовать данные из ваших первых столбцов (например, 'mediatype') для выполнения определенных процедур синтаксического анализа, если это необходимо, и использовать поля VARCHAR / VARBINARY в качестве входных данных. Масштабирование до новых типов встраиваемых носителей будет таким же простым, как написание нового (или расширение существующего) парсера и определение нового значения «mediatype».

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