Всем привет. Подскажите пожалуйста. Вот у меня есть разные категории

продуктов (к примеру телефон, ноутбук). У этих товаров разные виды характеристик. Получается мне нужен отдельно делать модель для ноутбука, отдельно для телефона. А как мне вывести при открытии категории телефоны на сайте одни фильтры, при открытии ноутбуки другие и тд?

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

Так документные БД, как эластик или монга, как раз в жсоне и хранят данные. Зачем переливать из пустого в порожнее, если жсон поддерживается всеми современными БД? Да не надо так делать все таки.

Когда это эластик стал документной бд?)

Монго хранит не в жсонах, а в коллекциях

В таких случаях советуют использовать EAV-архитектуру https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

Встречный вопрос - а когда перестал?

Так это поисковая система на основе люцена, а не самостоятельная база

Ну допустим. И какой вывод из этого утверждения? И монга и эластик работают с документами по рест-апи. У эластика определенные ограничения на вложенность - по-сути он именно документный. Т.е. сохранненный документ всегда уплощается, если туда пытаются вложить жсоновский словарь

Ну а по чему она ищет? Данные как хранятся?

Хватит бред писать, плес

А если не перестану, то ты громко заплачешь? Профессиональный аргумент. Я с эластиком больше года работал. Ты волен привести пруфы на свои утверждения.

Ну вот, я также волен сказать, что ты несёшь какой-то бред, работая больше года фиг знает где. Ну удачи, че сказать

Ну смотри, ты утверждаешь что эластик не поддерживает документы. Я прошу тебя пруфы.

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

А что меня остановит? O_0

https://www.elastic.co/what-is/elasticsearch ну вот, специально для тебя загуглил определение этого инструмента. Но ты можешь хоть трусы на голову одевать, тут дело твое

Ну да, все правильно > An Elasticsearch index is a collection of documents that are related to each other. Документное хранилище с богатым функционалом по тестовому поиску.

Вот скажи, какой нормальный человек будет параметры товаров в эластике хранить? Если это прям не очень специфичное решение

И они не хранят в жсоне, там документы подобные, но не они

Допустим не нормальный. Но в чем проблема-то?

Если большинство полей общие, почему бы не унаследовать?

если у тебя есть какая-то мысль раскрой ее

https://t.me/pydjango/555827

Может абстрактную модель сделать?

И потом 100500 наследников к ней?

Ну да, неудобно

Сделать textarea с макросами и вусивуг, сделать jsonfields с парс выводом доп полей Два решения которые я нашел когда было нужно

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

А их не многа будет? Хотя тем не менее тож норм вариант, для поиска особенно

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

так это и есть eav

буду знать, спасибо

В этом и суть - либо у тебя будет таблица с сотнями полей общих для всех видов товаров, либо ты создаешь кучу аттрибутов типа "характеристика". В оригинальной статье на вике разбирается пример с медицинскими записями где у пациента может быть сотня типов жалоб https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model The example below illustrates symptoms findings that might be seen in a patient with pneumonia. (<patient XYZ, 1/5/98 9:30 AM>, <Temperature in degrees Fahrenheit>, "102" ) (<patient XYZ, 1/5/98 9:30 AM>, <Presence of Cough>, "True" ) (<patient XYZ, 1/5/98 9:30 AM>, <Type of Cough>, "With phlegm, yellowish, streaks of blood" ) (<patient XYZ, 1/5/98 9:30 AM>, <Heart Rate in beats per minute>, "98" )

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

Да вы гоните чтоли? Уже даже аппликуха есть готовая https://github.com/jazzband/django-eav2