Столкнулся с подобными анкетными формами заполнения данных, вот пример радио списка:
Комиссия на снятие наличных в банкоматах сторонних банков:
• Не взимается
• _________%
• _________% не менее ____ руб.
• __________руб.
Если по-простому решить, то надо завести 2 поля: для % и для руб. При выводе определять: если null в обоих, то Не взимается. если 2 поля заполнены, то 3й вариант. Причем если администратор захочет поменять вариант на Не взимается, то надо занулить 2 поля. Меня вся эта логика коробит, т.к. подобных полей много, и хочется спросить, как вы храните подобные данные.
Вот еще примеры, может подобные анкеты должны вручную заполняться ?
Кредитный лимит
• Рассматривается персонально
• до ________ руб.
Беспроцентный период
• Есть, до _____ дней
• нет
Как хранить подобные данные
Как хранить подобные данные
RTFM !
Re: Как хранить подобные данные
я бы делал на каждое ___ по полю в бд + 1 поле-флаг, который бы указывал какой вариант выбран, флаг можно вынести в select( а нужный инпут отображать уже через js) или radio
Re: Как хранить подобные данные
про флаг спасибо за наводку ) однако как-то напрягает, штук 6 таких анкетных вопросов, получаешь ~ 18 полей в таблице ) но видимо ничего не поделаешь
RTFM !
Re: Как хранить подобные данные
да, меня тоже сначала напрягало, зато удобно, уже привыкbecause писал(а):про флаг спасибо за наводку ) однако как-то напрягает, штук 6 таких анкетных вопросов, получаешь ~ 18 полей в таблице ) но видимо ничего не поделаешь
Re: Как хранить подобные данные
Кстати поскольку считаете деньги, то важным моментом является то, что деньги надо всегда считать только в каком-либо одном месте (ну или на одной стороне), ну а точности до тысячных впринципе хватит. =)
Re: Как хранить подобные данные
раз такая тема, вот еще что меня периодически гложет. есть списки значений для выбора, в селектах или радио.
и форма полна полей со списками для выбора значений.
варианты:
1) создать 1 таблицу на каждый список id | name.
2) захардкодить в модели как константы + массивы.
3) завести словари значений, эдакий dictionary: словари и их значения - 2 таблицы.
1 вариант неудобен БД наводняется тучей таких таблиц, + постоянная рутина по их созданию.
2 вариант тоже, засоряется модель
3 лишен недостатков первых двух, + если иметь интерфейс, то списки (словари) удобно редактируются
однако есть еще один момент, значения в списках чекбоксов. опять-таки, надо каждый раз создавать таблицу отношений, которую надо постоянно очищать, если будет происходить обновление данных. хорошо когда это 2-5 раз в проекте встретится, а когда весь проект такой...
Возможно ли заменить создание таблиц отношений на универсальную таблицу ?
table_name - таблица
list_name - идентификатор списка значений
value
Стоит ли думать в таком направлении, или классический подход с таблицами лучше ?
и форма полна полей со списками для выбора значений.
варианты:
1) создать 1 таблицу на каждый список id | name.
2) захардкодить в модели как константы + массивы.
3) завести словари значений, эдакий dictionary: словари и их значения - 2 таблицы.
1 вариант неудобен БД наводняется тучей таких таблиц, + постоянная рутина по их созданию.
2 вариант тоже, засоряется модель
3 лишен недостатков первых двух, + если иметь интерфейс, то списки (словари) удобно редактируются
однако есть еще один момент, значения в списках чекбоксов. опять-таки, надо каждый раз создавать таблицу отношений, которую надо постоянно очищать, если будет происходить обновление данных. хорошо когда это 2-5 раз в проекте встретится, а когда весь проект такой...
Возможно ли заменить создание таблиц отношений на универсальную таблицу ?
table_name - таблица
list_name - идентификатор списка значений
value
Стоит ли думать в таком направлении, или классический подход с таблицами лучше ?
RTFM !