AI
но вообще это чет не то: если пользователь - нормальная компания, им неудобно будет один и тот же параметр копипастить постоянно
Size: a a a
2020 September 06
AI
а если вдруг надо переименовать - жжжопа
DP
Там есть ещё таблица вида:
параметр - тип инпута (select, text, checkbox, radio) и подпись к свойству
На основе этой табличке джанго генерит форму для сотрудника
параметр - тип инпута (select, text, checkbox, radio) и подпись к свойству
На основе этой табличке джанго генерит форму для сотрудника
G
Да, спасибо
Но тут у всех товаров одинаковый произвольно изменяемый пользователем набор.
Но тут у всех товаров одинаковый произвольно изменяемый пользователем набор.
как часто изменяемый? надо ли фильтровать по этим своиствам? какая дб?
DP
Gas
как часто изменяемый? надо ли фильтровать по этим своиствам? какая дб?
Фильтровать надо
Изменяют не очень часто (ежемесячно), БД - MySQL
Изменяют не очень часто (ежемесячно), БД - MySQL
AI
если фильтровать надо, тогда однозначно две модели надо
AI
надо отдельно фиксировать для каждой категории набор фильтров
AI
и потом уже обозначать показания по фильтрам в отношении конкретного продукта
G
если не часто, я б нааерно выбрал вариант (1)
NC
Добрый день.
Нужен совет относительно хранения данных.
Предположим, у меня есть таблица содержащая столбцы id и name (имя объекта).
Пользователь через админку приложения должен иметь возможность добавлять и удалять свойства объектов.
И у меня пока 2 идеи:
(1) Каждому свойству сделать свой столбец в таблице. Т.е. добавление свойства - это добавление столбца в таблицу,
(2) Сделать JSON поле attrs (attributes) в таблице, в котором в JSON формате хранить словарь, содержащий свойства объектов.
Нужен совет относительно хранения данных.
Предположим, у меня есть таблица содержащая столбцы id и name (имя объекта).
Пользователь через админку приложения должен иметь возможность добавлять и удалять свойства объектов.
И у меня пока 2 идеи:
(1) Каждому свойству сделать свой столбец в таблице. Т.е. добавление свойства - это добавление столбца в таблицу,
(2) Сделать JSON поле attrs (attributes) в таблице, в котором в JSON формате хранить словарь, содержащий свойства объектов.
отдельная таблица с фк и свойством объекта?
AD
Да элементарный пример подсчет числа пересекающихся интервалов для каждой точки... Каких только "чудес" не насмотришься... А это не такая уж редкость для задач планирования. Даже если их решают веб-приложением.
Веб-разработка - это не только бложики и каталоги.
Веб-разработка - это не только бложики и каталоги.
1) если вы решаете саенс задачу оборачивая ее веб-приложением, это никак не доказывает, что веб-девелопмент требует познаний в математике выше элементарных. мой уловитель различных аудио паттернов, например, тоже был обернут в джанго интерфейс, но делая core приложения, я не был в роли веб девелопера. Веб девелопер решает проблемы веб-приложения.
2) У вас сквозит какое-то пренебрежение к веб-девелопменту. Накидать на коленке булщит апп не составляет труда. Но веб изменился и веб-разработка сегодня достаточно много требует от разработчика для построения грамотного приложения. Там нет никаких экстра сложных сущностей, но пласт информации требующий освоения очень объемен.
3) У меня закрадывается подозрение, что вы не находитесь в поле аутсорс-разработки. Такие плавающие критерии больше свойствены продактовым компаниям, например, где чаще встречается смешивание ролей. В аутсорс-разработке я вижу относительно неплохое разграничание ролей и зон ответственности, и как следствие, повышения качества производимых решений. На абстрактное "веб-девелопер" можно навешать много ролей и задач, при желании - и сайенс, и администрирование (попытка накинуть сверху роль девопса), и фронты, и еще как минимум несколько ролей. Кому и зачем нужен такой сотрудник, умеющий все, но плохо? - только жадному работодателю, который любит концепцию all-in-one.
При этом, не вижу ничего плохого science + backend, но давайте называть вещи своими именами.
Решение задач бизнес логики через сложные математические отношения - это не проблема веб разработки.
2) У вас сквозит какое-то пренебрежение к веб-девелопменту. Накидать на коленке булщит апп не составляет труда. Но веб изменился и веб-разработка сегодня достаточно много требует от разработчика для построения грамотного приложения. Там нет никаких экстра сложных сущностей, но пласт информации требующий освоения очень объемен.
3) У меня закрадывается подозрение, что вы не находитесь в поле аутсорс-разработки. Такие плавающие критерии больше свойствены продактовым компаниям, например, где чаще встречается смешивание ролей. В аутсорс-разработке я вижу относительно неплохое разграничание ролей и зон ответственности, и как следствие, повышения качества производимых решений. На абстрактное "веб-девелопер" можно навешать много ролей и задач, при желании - и сайенс, и администрирование (попытка накинуть сверху роль девопса), и фронты, и еще как минимум несколько ролей. Кому и зачем нужен такой сотрудник, умеющий все, но плохо? - только жадному работодателю, который любит концепцию all-in-one.
При этом, не вижу ничего плохого science + backend, но давайте называть вещи своими именами.
Решение задач бизнес логики через сложные математические отношения - это не проблема веб разработки.
.
Жаль здесь лайки ставить нельзя
😂
😂
G
создай опрос с лайк / дислайк😄
D
Как правильно задать ALLOWED_HOSTS в .env?
YD
Это такая секретная инфа что нельзя оставлять в settings.py?
D
ALLOWED_HOSTS=domain.com,127.0.0.1
ALLOWED_HOSTS = tuple(env.list('ALLOWED_HOSTS', default=[]))
Вот так работаетYD
ALLOWED_HOSTS=domain.com,127.0.0.1
ALLOWED_HOSTS = tuple(env.list('ALLOWED_HOSTS', default=[]))
Вот так работаетАаа, это должен быть список строк и вс будет ок)
D
Это такая секретная инфа что нельзя оставлять в settings.py?
Да нет, но интересно
YD
ALLOWED_HOSTS = ['domain.com', '127.0.0.1']