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

0

Я работаю над секцией внедрения на моем сайте, где пользователи могут вставлять разные медиафайлы из различных сервисов, youtube, myspace music, vimeo и т.д.

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

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

  • embedid (первичный ключ с автоматическим добавлением),
    userid, embedded_item_id (например, youtube id)

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

  • userid, youtubeid, vimeoid,
    myspaceid1, myspaceid2

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

Теги:
database
database-design

2 ответа

1
Лучший ответ
  • В таблице "EmbededItem" есть столбцы, общие для всех элементов.
  • YouTube, Vimeo, MySpace имеют только столбцы, специфичные для каждого из них.

    Изображение 174551
Поделиться
  • 0
    вау ... никогда не ожидал картинки ... хммм да, имеет большой смысл ... очень реляционный :)
  • 0
    Почему бы не иметь одну таблицу для всех уникальных идентификаторов с таблицей сопоставления для разных имен служб. С этой настройкой вам нужно будет добавлять новую таблицу каждый раз, когда вы хотите добавить поддержку новой службы. С таблицей сопоставления вы просто добавляете новую строку.
Показать ещё 9 комментариев
0

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

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

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

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

  • Вы можете хранить данные как любой формат данных, который может понадобиться вашему приложению (сериализованный объект для java, JSON для javascript и т.д.). Если вы сериализуете объект, вам может потребоваться больше 4k пространства, а поле VARBINARY, а не VARCHAR.

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

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

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

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

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню