Nano Hash - криптовалюты, майнинг, программирование

Подходы к расширяемым пользователем сущностям с реляционной базой данных (mySQL)

У нас есть система php/mysql с примерно 5 основными объектами. Теперь нам нужно добавить возможность для клиентов создавать настраиваемые поля для некоторых из этих сущностей для каждого проекта.

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

Это делается для того, чтобы они могли добавить настраиваемое поле даты или настраиваемое раскрывающееся меню в пользовательский интерфейс и сохранить это значение для определенного объекта.

Как лучше всего хранить такие данные в базе данных MySQL? Мне нужно сохранить как конфиг для поля, так и текущее значение для конкретного объекта.

Здесь я рассмотрел различные варианты. https://ayende.com/blog/3498/multi-tenancy-extensible-data-model

Но на самом деле это не уровень аренды, а уровень проекта.

Я подумал...

  • Таблица CustomFields для хранения конфигурации поля по типу сущности и идентификатору проекта.
  • Таблица CustomFieldValues ​​для хранения значения, сохраненного для поля — строка для каждого поля ( entity_id | field_id | field_value)

Затем мы создаем отношения между сущностями и этими пользовательскими значениями при извлечении сущностей.

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

Кроме того, вы не можете индексировать поля по имени, я думаю, что соединения станут довольно сложными, поскольку вам нужно присоединиться к конфигурации и значениям, чтобы построить пару значений ключа, чтобы вернуться к объекту, и как бы вы выбрали на основе имя пользовательского поля, когда имя поля на самом деле было значением?

Я не хочу добавлять в таблицу динамические столбцы, так как это повлияет на ВСЕ сущности во всей системе, а не только на те, что в текущем клиенте/проекте.

Другой вариант — сохранить значения в столбце JSON.

Это может быть в самой строке объекта customFields или аналогичной. Это предотвратит появление дополнительных строк в поле, но также имеет проблемы с отсутствием индексации и т. д., и все равно необходимо присоединиться к таблице конфигурации. Однако вы можете выполнять запросы по имени свойства, если key=value хранится в JSON... WHERE entity.customFields->"$.myCustomFieldName" > 1.

Хранение имени файла в json означает, что вы не можете изменить его после создания без особых проблем.

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

mysql php database-design entities entity-attribute-value
26.01.2017

Ответы:


1

Записи JSON: Нет! Тысячу раз нет! Если вы это сделаете, просто подождите, пока кто-то действительно не использует вашу систему для нескольких десятков миллионов записей, а затем попросит вас выполнить поиск в одном из ваших дополнительных полей. Люди из вашей поддержки будут проклинать ваше имя.

Хранилище ключей-значений. Вероятно, да. Существует очень широко распространенное доказательство существования этого дизайна: WordPress. У него есть таблица с именем wp_postmeta, содержащая поля метаданных, применимые к wp_posts (страницам блога и сообщениям). Это оказалось успешным.

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

 SELECT p.person_id, p.first, p.last, h.value height, e.value eye_color
   FROM person p
   LEFT JOIN attrib h ON p.person_id = h.person_id AND h.key='eye_color'
   LEFT JOIN attrib e ON p.person_id = e.person_id AND e.key='height'
  WHERE e.value='green' and CAST(h.value AS INT) <  160

Как показывает CAST в предложении WHERE, у вас также возникнут проблемы с типом данных.

Вам понадобятся операции LEFT JOIN в таком поиске атрибутов; обычные внутренние операции JOIN будут подавлять строки с отсутствующими атрибутами, и это может не сработать для вас.

Но если вы хорошо справитесь с индексами, вы сможете получить достойную производительность при таком подходе.

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

26.01.2017
  • Ну, я не согласен. Ключ-значение отстой больше, чем JSON. Я предпочитаю компромисс между явными столбцами (для нескольких вещей) и JSON для произвольного мусора. См. тег EAV для многих других вопросов и ответов по этой общей теме. 27.01.2017
  • да - я полагаю, что эти два ответа суммируют мою дилемму! Я почитаю посты EAV... 06.02.2017
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..