Как организовать структуру базы данных для динамических характеристик?

Question

[Flaker]

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

Конкретнее: Есть дома. У домов есть характеристики. Значения этих характеристик могут быть числом, строкой или boolean'ом. Нужно организовать базу так, что бы характеристики можно было добавлять. При этом значения для одной и той же характеристики у каждого дома свое. При этом нужно будет организовать фильтрацию по этим характеристикам.

Мой вариант:


При использовании MySQL, так как сейчас изображено у меня на картинке, всю фильтрацию придется проводить через CAST или CONVERT.

Вот я и думаю, как лучше организовать подобное.

Answer 1

[Станислав Макаров]

Как добавить товар в корзину?

- EAV (ссылку дал @muhammad_97);
- JSON/XML в реляционной базе;
- JSON в документной базе (CouchDB/MongoDB) (предпочтительный вариант);

Comments

[Flaker]

При использовании JSON есть 2 варианта исхода:
1) Все характиристики лежат внутри property. Для каждого property свой набор характеристик, не связанных с другими наборами характеристик.
Какие плюсы?
Удобно организовывать фильтрацию. (При поддержке фильтрации по Json)
Какие минусы?
Изменения данных одной характеристики не затрагивают изменения в других характеристиках. (Например для изменения имени характеристики придется менять все строки таблицы)
2) Внутри property лежат ссылки на id характеристик и их значения.
Тут мы по сути вернемся к Реляционной модели базы.
Хотя, конечно, производительность может быть будет выше.
Это то как я себе представляю использование подхода с Json...
Но у меня практически нет опыта в этом, поэтому и обратился к тем кто сможет подсказать.

[Андрей Андреев]

Станислав Макаров извините немного не по теме, но не знаете ли вы случайно, подходит ли сюда Postgresql с hstore и не является ли это плохой практикой?

[Станислав Макаров]

Андрей Андреев не приходилось использовать hstore, насколько мне известно это чтото вроде упрощенного json, где все атомарные значения - строки (это надо проверить, могу ошибаться). В целом, он подходит для описанной ситуации.

[Станислав Макаров]

> 1) Все характиристики лежат внутри property. Для каждого property свой набор характеристик, не связанных с другими наборами характеристик.

вообще не понял смысл этого утверждения. я предлагаю очень просто: для каждого дома у вас JSON-документ (неважно - документ ли в это в Монге, или же значение колонки Properties в таблице), в этом документе у вас по одному ключу для каждой характеристики. Чтобы не было проблемы "переименования" характеристики, можете отдельно хранить отображаемое название, чтобы его менять (чтобы не менять все документы).

Честно говоря совсем не понял вашу таблицу "характеристики свойств". Если у вас стоит проблема типа хранимого значения, то с JSON-ом ее не будет по определению.
В общем и целом я не вижу у вас схемы как таковой. Для меня логично в этой ситуации работать с полуструктурированными данными (XML или JSON особого значения не имеет, хотя последний подходит чаще).

[Станислав Макаров]

Flaker пинг

[Станислав Макаров]

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

[Flaker]

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

Что бы говорили на одном языке:
1) "property" — в данном случае, я называю дом/квартиру/участок (Недвижимость), а не свойство. (Это, по сути, наш Entity)
2) "characteristic" — это характеристика недвижимости (property). Характеристикой может быть цена, площадь участка и т.д.

Я не совсем понимаю как организовать структуру в документной базе.
Разве, если мы вынесем все данные о характеристиках в отдельный документ (Для того что бы можно было имя переименовать только в одном месте), а значения будем хранить вместе с "property", не будет ли это, по сути, реляционной структурой?

P.S. Нет ли для документых баз удобного инструмента визуального проектирования?

P.S.S. В этой ветке сейчас закончится кол-во возможных ответов. Есть ли возможность связаться как-то вне этой ветки?

[Станислав Макаров]

Flaker
> "property" — в данном случае, я называю дом/квартиру/участок (Недвижимость), а не свойство.
> "characteristic" — это характеристика недвижимости (property)
Вот это поворот)) Хорошо что сказали.

> а значения будем хранить вместе с "property", не будет ли это, по сути, реляционной структурой?
у реляционной структуры есть схема. У всех кортежей одного отношения схема одинакова по определению, иначе быть не может. У вас же в каждом документе может быть свой набор характеристик для entity. Даже если данные о САМИХ характеристиках соберете где-то еще (например, их отображаемое название), это не значит, что каждая конкретная характеристика должна встречаться в каждом документе - это вам и нужно, как я понимаю.

Дошло до меня, "property" это "собственность" что-ли?)) Почему не estate - недвижимость?)

[Flaker]

Станислав Макаров: property как-то первым на ум пришло)

Да, это то что и нужно.

[Flaker]

Станислав Макаров: То-есть структуру стоит сделать таким образом?

https://habrastorage.org/files/9ec/185/6c5/9ec1856...

Answer 2

[Muhammad]

EAV: https://en.m.wikipedia.org/wiki/Entity–attribute–v...

Comments

[Flaker]

Спасибо за ссылку на статью. Отличный материал. Но я не совсем понял его.
Вернее я не понял, является ли мой текущий набросок структуры разновидностью EAV. Судя по всему является. В таком случае, как в статье и сказано, я использую текстовое поле для хранения значения, что, скорее всего приведет к падению производительности при поиске с использованием CAST.

В статье сказано, что "larger systems use separate EAV tables for each data type". Является ли это оправданным на системе в которой ~1000 Entity и к каждой ~20 Attribute?

[Muhammad]

Flaker: думаю нет, таблица получается не такая большая (20k записей)

[Flaker]

Muhammad: Вы скажите, то как организовано у меня, можно считать EAV?

И будет ли более-правильно перейти на документные базы?

[Muhammad]

Flaker: не спец в этой теме, но, когда я искал решение подобного вопроса, советовали использовать NoSQL базы данных, например, MongoDB

[Flaker]

Muhammad: Понятно, спасибо)

Answer 3

[DVamp1r3]

Возможно также поможет сериализация объектов в строку

Comments

[Flaker]

Вы, по сути, имеете ввиду использование JSON?

Answer 4

[heartdevil]

В таблице characteristics сделайте конкретно три поля, вместо type

Id (int)
name (varchar)
string_option (varchar)
number_option (int/float/decimal)
bool_option (boolean)
prefix (varchar)
suffix(varchar)

И храните выборочно значения для каждого поля

Comments

[Flaker]

А что хранить в этих трех полях?

[Flaker]

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

[heartdevil]

Flaker: значения, которые могут быть у вач числом, строкой или логическим значением. Потом вы пишите про cast или convert. Я так понял -- это связано именно с тем, что у вас type разно типа может быть. Вот я вам и предложил конкретными типами хранить ваши характеристики. А что там к вам приходит, я не знаю).

[Flaker]

heartdevil: Да, но кроме того что у value могут быть разные типы, они еще должны быть разные для каждого property. Поэтому вариант со статическими полями value не проходит.

[heartdevil]

Flaker: Понятно. Если я правильно понял, то можно перенести конкретные поля характеристик с конкретными типами прям в вашу перекрестную таблицу property_characteristics. В зависимости от характеристики заполнять поля. Выглядит денормализовано, но зато будете работать с конкретными типами, вместо всякого неудобного, а иногда и дорого кастинга.

[Flaker]

heartdevil: Да, тоже об этом думаю... Пока только копаю информацию, что бы сделать качественно и красиво.

Answer 5

[DastiX]

Как лучше хранить настройки пользователей в БД?

Comments

[Flaker]

Интересно, но я не понимаю, как применять в рамках данного вопроса.

Тут есть 2 ключевых отличия:
1) Характеристики могут быть не только boolean, а так же и string и number.
2) Нужно реализовывать поиск по характеристикам.

Все-таки я не очень хорошо понял идею "виртуальных столбцов", поясните, если не сложно.

[DastiX]

1) Делаете отдельно Таблицу реальных значений(xval) с полем val boolean, отдельно string, отдельно number.
Итого три таблицы на все случаи жизни.
2) Выбираете из Таблицы реальных значений те значения, которые Вас устраивают и все.

Есть основная таблица. Дома. Есть Варианты характеристик домов. Т.е. какие характеристики МОГУТ быть у дома.
Есть таблица реальных значений этих характеристик с привязкой к дому.
ДОМ->ХАРАКТЕРИСТИКА->РЕАЛЬНОЕ ЗНАЧЕНИЕ.
Понятнее?