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

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

1 голос
/ 12 января 2011

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

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

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

Так что теперь я застрял с множествомтаблиц.

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

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

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

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

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

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

свойстваproperties_imagesproperties_listingsproperties_optionsproperties_purposesres_geo_addressres_geo_citiesres_geo_neighborhoodsres_geo_statesres_property_optionsres_property_type_ageres_property_type_listingres_property_type_propertyres_property_type_purposeres_property_type_purpose_property

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

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

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

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

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

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

alt text

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

Ответы [ 2 ]

1 голос
/ 13 января 2011

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

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

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

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

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

Удачи!

1 голос
/ 12 января 2011

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

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

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

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

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

...