Алексей Лебедев: Смена максимального значение — является операцией вставки.
Какая разница, как часто оно меняется, если без коллизий это будет константой по времени?
Интересно, но я не понимаю, как применять в рамках данного вопроса.
Тут есть 2 ключевых отличия:
1) Характеристики могут быть не только boolean, а так же и string и number.
2) Нужно реализовывать поиск по характеристикам.
Все-таки я не очень хорошо понял идею "виртуальных столбцов", поясните, если не сложно.
Станислав Макаров: Спасибо вам за подробный ответ. Скажу сразу, я почти никогда не работал с документными базами, поэтому могут возникать недопонимания.
Что бы говорили на одном языке:
1) "property" — в данном случае, я называю дом/квартиру/участок (Недвижимость), а не свойство. (Это, по сути, наш Entity)
2) "characteristic" — это характеристика недвижимости (property). Характеристикой может быть цена, площадь участка и т.д.
Я не совсем понимаю как организовать структуру в документной базе.
Разве, если мы вынесем все данные о характеристиках в отдельный документ (Для того что бы можно было имя переименовать только в одном месте), а значения будем хранить вместе с "property", не будет ли это, по сути, реляционной структурой?
P.S. Нет ли для документых баз удобного инструмента визуального проектирования?
P.S.S. В этой ветке сейчас закончится кол-во возможных ответов. Есть ли возможность связаться как-то вне этой ветки?
heartdevil: Да, но кроме того что у value могут быть разные типы, они еще должны быть разные для каждого property. Поэтому вариант со статическими полями value не проходит.
Спасибо за ссылку на статью. Отличный материал. Но я не совсем понял его.
Вернее я не понял, является ли мой текущий набросок структуры разновидностью EAV. Судя по всему является. В таком случае, как в статье и сказано, я использую текстовое поле для хранения значения, что, скорее всего приведет к падению производительности при поиске с использованием CAST.
В статье сказано, что "larger systems use separate EAV tables for each data type". Является ли это оправданным на системе в которой ~1000 Entity и к каждой ~20 Attribute?
Если вы имеете ввиду хранить в них значения, то вы не совсем верно поняли связь.
У одной и той же характиристики могут быть разные значения для разных property
При использовании JSON есть 2 варианта исхода:
1) Все характиристики лежат внутри property. Для каждого property свой набор характеристик, не связанных с другими наборами характеристик.
Какие плюсы?
Удобно организовывать фильтрацию. (При поддержке фильтрации по Json)
Какие минусы?
Изменения данных одной характеристики не затрагивают изменения в других характеристиках. (Например для изменения имени характеристики придется менять все строки таблицы)
2) Внутри property лежат ссылки на id характеристик и их значения.
Тут мы по сути вернемся к Реляционной модели базы.
Хотя, конечно, производительность может быть будет выше.
Это то как я себе представляю использование подхода с Json...
Но у меня практически нет опыта в этом, поэтому и обратился к тем кто сможет подсказать.
