Array, EAV, Serialized LOB для пользовательских полей? - PullRequest
8 голосов
/ 11 октября 2010

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

Текущая база данных - это реляционная база данных, и каждый пользователь службы будет использовать одну и ту же базу данных и таблицы.

Вот примеро том, что я пытаюсь сделать.

Допустим, я пытаюсь создать список.Этот список может содержать до 30 пользовательских полей.Пользователь может выбирать между 12 уникальными элементами, и каждый элемент может иметь до 15 определенных пользователем атрибутов.

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

Элементом может быть множество вещей, например: множественный выбор, переключатель, поле телефона, адрес, однострочный текст, многострочный текст и т. Д.

Пример атрибутов дляЭлемент множественного выбора (флажок) может быть: красный, зеленый, синий, оранжевый, белый, черный

Примером однострочного текстового элемента может быть: Поле ввода имени.

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

Сегментация также очень важна.Пользователь должен иметь возможность сегментировать список на основе любого элемента.Например, пользователь может захотеть сегментировать список «ABC» на основе всех записей, где «красный» присутствует в элементе № 1 с множественным выбором (он может иметь более 1 элемента с множественным выбором для списка).

В этом примере я бы предположил, что массивы EAV, Serialized LOB будут работать нормально.Тем не менее, я не уверен, что будет наилучшей структурой для моих потребностей в моем масштабе.

В действительности, в каждом списке, скорее всего, будет до 50 000 записей, и существует реальная возможность более 20 000 учетных записей - каждая с многочисленными списками.Поэтому я ищу наиболее эффективную и гибкую структуру.

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

Я просмотрел множество сообщений EAV на этом сайте, а также http://www.martinfowler.com/eaaCatalog/serializedLOB.html Не похоже, что EAV будет очень эффективным для моих нужд из-за недостатков поиска данных.

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

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

Ответы [ 2 ]

1 голос
/ 16 ноября 2011

Вы можете прочитать о том, как FriendFeed реализует пользовательские поля: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Они используют комбинацию Serialized LOB с дополнительными таблицами, содержащими инвертированные индексы. Вам не нужна дополнительная таблица для каждого возможного атрибута в вашем большом объекте, только те, которые вы хотите найти с помощью индекса.

0 голосов
/ 15 ноября 2011

Вы можете использовать json enconding и decoding (я предполагаю, что вы используете PHP) для хранения входной информации в таблице с колонкой для хранения пользователя и других для сохранения этих данных в виде текста. Ответы должны быть сохранены в другой таблице (с FK для использования CASCADE ON DELETE).

Если вы можете указать максимальный размер входной спецификации, используйте поле varchar.

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

...