Хобрук: Ваш путь к мастерству в программировании

Несколько значений MySQL в полях, EAV и т. д.

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

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

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

Итак, теперь я застрял с множеством столов.

Таблица для свойств, затем таблицы для значений, затем таблицы, которые присоединяют эти значения к свойствам.

Простой поисковый запрос без фильтров (больше фильтров, больше объединений). У меня 7 внутренних объединений.

Мне очень трудно заставить объединения работать как для ограничения результатов, так и для возврата значений в части SELECT запроса.

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

ИЗМЕНИТЬ:

На данный момент у меня есть следующие таблицы:

свойства
свойства_изображения
свойства_списки
свойства_параметры
свойства_цели
res_geo_address
res_geo_cities
res_geo_neighborhoods
res_geo_states
res_property_options
res_property_type_age
res_property_type_listing
res_property_type_property
res_property_type_assign
res_property_type_purpose_property

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

Таблицы properties_ используются для соединения таблицы properties и таблиц res_property_ (используя идентификаторы — один для свойства и один для значения) (исключением являются изображения, которые содержат только записи изображений)

В таблицах res_ по большей части перечислены идентификаторы и имена значений. (исключение составляют таблицы res_geo)

На данный момент мои запросы не работают. Честно говоря, я дошел до такой сложности, что мне трудно объяснить мою текущую настройку.

Было бы неплохо, если бы был простой способ запрашивать таблицы с полями, содержащими массивы, и легко извлекать их.

РЕДАКТИРОВАТЬ 2:

альтернативный текст

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

mysql database schema database-design entity-attribute-value
12.01.2011

  • Пожалуйста, опишите таблицы, которые вы создали, и, в частности, как работает ваш поиск значений. В общем, нет ничего плохого в множестве таблиц, если они правильно моделируют данные, которые вы пытаетесь сохранить. 12.01.2011
  • Как я часто делаю в вопросах, связанных с EAV: weblogs.sqlteam.com/davidm/articles/ 12117.aspx - просмотрите эту статью и обратите внимание на ее последнюю фразу. 12.01.2011

Ответы:


1

Если это то, что вы описываете:

           Entity
             ^
             |
     EntityPropertyValue
             |
             |
Property<----      PropertyValue
   ^                     |
   |                     |
    ---------------------

Где Property определяет различные свойства, которые могут быть применены к данному Entity, PropertyValue определяет значения, допустимые для данного Property, а EntityPropertyValue определяет значение данного свойства для данного Entity, тогда то, что у вас есть, в значительной степени соответствует EAV. (просто замените слово Attribute на Property, и вы получите именно EAV).

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

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

12.01.2011

2

Похоже, вы стали жертвой очень плохого совета использовать целочисленный ключ для всего, даже для простых таблиц, в которых есть только один реальный столбец со значениями, такими как «Продажа», «Аренда» и т. д.

Ваша таблица RES_PROPERTY_TYPE_LISTING должна иметь только один столбец «TypeCode» (использование «кода» — очень старое соглашение для использования первичных ключей символов), который является первичным ключом.

Теперь вы можете удалить одну таблицу, потому что PROPERTIES_LISTINGS выглядит так:

ID_PROPERTY    TypeCode
-----------    ---------
     1           Sale
     1           Rent
     2           Rent

Что касается идеи о том, что целые числа обеспечивают более быстрое соединение, мы только что исключили JOIN, и самое быстрое соединение — это то, которое вам не нужно делать. Оставшийся JOIN по-прежнему находится в целых числах, поэтому вы в безопасности, когда достигнете 10 000 транзакций в секунду, потому что до этого вы никогда не увидите разницы.

Удачи!

13.01.2011
  • Мне все равно нужна третья таблица для обеспечения целостности при вставке да? 13.01.2011
  • Да, но только для РИ. При запросе вы игнорируете его. Вы можете сделать это и для состояний, и, возможно, один или два других должны сильно упростить ситуацию. 14.01.2011
    • Новые материалы
    Как свинг-трейдеры могут использовать ИИ для больших выигрышей
    По мере того как все больше и больше профессиональных трейдеров и активных розничных трейдеров узнают о возможностях, которые предоставляет искусственный интеллект и машинное обучение для улучшения..
    Как построить любой стол
    Я разработчик программного обеспечения. Я люблю делать вещи и всегда любил. Для меня программирование всегда было способом создавать вещи, используя только компьютер и мое воображение...
    Обзор: Машинное обучение: классификация
    Только что закончил третий курс курса 4 часть специализации по машинному обучению . Как и второй курс, он был посвящен низкоуровневой работе алгоритмов машинного обучения. Что касается..
    Разработка расширений Qlik Sense с qExt
    Использование современных инструментов веб-разработки для разработки крутых расширений Вы когда-нибудь хотели кнопку для установки переменной в приложении Qlik Sense? Когда-нибудь просили..
    React Hooks: основы деструктуризации массива
    Kent C. Dodds написал классный пост о том, как грядущая функция React под названием Hooks работает на капоте. Предстоящий хук React useState основан на деструктурировании массива, давайте..
    Пакеты R, используемые в Tesla
    Добро пожаловать обратно! R — очень популярный язык программирования, используемый множеством компаний, включая Tesla! Итак, давайте взглянем на некоторые пакеты R, которые использует Tesla...
    Сокращение и слияние токенов для эффективных моделей VL: обзор
    Часто в задачах, связанных с компьютерным зрением и НЛП, вычислительно затратная и требующая большого объема памяти обработка становится препятствием для более быстрого логического вывода модели, а..