Форум сайта python.su
Добрый день.
На сайте есть один вид товара, разбитый по категориям.
Категории хранятся как константа внутри класса описывающего товар и в админке выглядят как выпадающий список.
Нужно иметь возможность редактировать этот список.
Создавать ли для категории отдельный класс (список категорий совсем небольшой), либо это можно сделать другими методами, например хранить его как xml файл, либо еще как-то.
Буду рад любым идеям, спасибо.
Офлайн
Редактировать, я так понимаю, из админки? Тогда лучше сделать новую модель и связать с товарами.
Офлайн
Спасибо.
Просто немного принципиально не понимаю смысл хранения этих скажем пяти категорий в отдельной таблице бд, но догадываюсь, что в этом случае это самый быстрый и безболезненный результат.
Офлайн
Количество тут не главное. Главное что тогда эти категории можно менять штатными средствами, просто пользователю. И очень просто.
Офлайн
Хм , а может все-таким сначала книжку про БД и 3НФ почитать ? Сразу масса вопросо отвалиться .. Как сказанно выше количество (если не считать вырожденных сллучаев ) не главное … Намного лучше изначально иметь правильную структуро объектов …. Сегодня нужен список , завтра - дерево ;) Потом ссылки на пачку товаров из категории ( m:m) Такчто IMHO имеет смысл сразу правильно делать ;)
Офлайн
MaddyИ отложить подальше:-) Зачастую в Вебе теория с практикой очень расходятся.
Хм , а может все-таким сначала книжку про БД и 3НФ почитать ?
Офлайн
DaevaornХм …. А с чего ? Пример можно ? Все-ведь зависит от задачи …..
И отложить подальше:-) Зачастую в Вебе теория с практикой очень расходятся.
Офлайн
MaddyТак общей спецификой веба как сервиса для пользователей с заданой производительностью. Он (пользовтаель) не будет 15 минут ждать пока ему отчет сгенерирует СУБД, “приджоинивая” 10 таблиц в одном запросе.
А и чем задача под веб отличаеться ( по работе с БД) от не веба ?
MaddyТак вот если влоб использовать джанговский ORM, то на грабли как раз и набредете. С ним надо аккуратно очень работать, чтобы не получить совсем большую просадку в производительности.
Раз уж данговский ОРМ влоб ползует реляционную модель - то наверное все-таки имеет смысл очевидные грабли обойти ?
MaddyКонечно от задачи. Ну вот допустим число комментариев к посту в блог - в 99% случае выгоднее держать денормализованным полем. И так очень во многом.
Хм …. А с чего ? Пример можно ? Все-ведь зависит от задачи …..
Офлайн
DaevaornНу это опять-таки смотря что за пользователь - если вольный серфер , то да … а если пользователь корпоратифффки - куды ему деваться - если велено “смотреть здеся!!!” ;)
Так общей спецификой веба как сервиса для пользователей с заданой производительностью. Он (пользовтаель) не будет 15 минут ждать пока ему отчет сгенерирует СУБД, “приджоинивая” 10 таблиц в одном запросе.
DaevaornА примеры возможных граблей можно ?
Так вот если влоб использовать джанговский ORM, то на грабли как раз и набредете. С ним надо аккуратно очень работать, чтобы не получить совсем большую просадку в производительности.
DaevaornЭто всмысле поле в таблице (в модели) или поле со списком id'шек коментов ?
Конечно от задачи. Ну вот допустим число комментариев к посту в блог - в 99% случае выгоднее держать денормализованным полем. И так очень во многом.
Офлайн
MaddyИ строем ходить:-) Заставить всегда можно, но лучше время ожидания сокращать всё-таки.
Ну это опять-таки смотря что за пользователь - если вольный серфер , то да … а если пользователь корпоратифффки - куды ему деваться - если велено “смотреть здеся!!!” wink
MaddyБанальнейший пример:
А примеры возможных граблей можно ?
class Article(models.Model):
author = models.ForeignKey(User)
# ...
articles = Article.objects.all()
# ...
{% for article in articles %}
<!-- ... -->
<p>Author: {{article.author}}</p>
<!-- ... -->
{% endfor %}
MaddyПока говорим о количестве комментариев - просто целочисленное поле с числом.
Это всмысле поле в таблице (в модели) или поле со списком id'шек коментов ?
Офлайн