|
Минимизация представлений данных: чушь или благо дя юзера?
|
||
|---|---|---|
Участник
Откуда: и зачем;
Сообщения: 4 817 |
||
| 09.07.2010, 09:43 |
|
|
|
|
|
Минимизация представлений данных: чушь или благо дя юзера?
|
|||
|---|---|---|---|
|
#18+
Озаботился тут оптимизаций свое програмки, после некоторого периода ее реального использования: Есть 4 основных сущности: клиент, абонемент, посещение, оплата В первом варианте сделал 4 таких вида просмотра данных (т.е. табличные за период) но что смущает, бОльшая часть информации в просмотрах абонемент, посещение, оплата совпадает, поясню: Абонементыклиентдата начала аб-тадата окончания аб-тасумма аб-тасумма оплатыостаток оплаты ... ПосещенияКлиентдата посещениявид занятиясумма (стоимость посещения сверх абонемента)сумма оплатыостаток оплаты... ОплатыКлиентдата оплатысумма оплатыдата абонемента или посещение (т.е. за что платим)вид абонемента или вид занятияклиент абонементы или посещения (один клиент может заплатить за другого) По сути, абонементы и посещения - это что продается (услуга) и их можно бы объединить в один журнал операций, как это сделать понятно например получается журнал операций: Журнал операцийклиент операциидата операциивид операции(абонемент/посещение/продажа товара...)сумма операциисумма оплатыостаток оплаты Оплатыклиент оплаты (кто платит)дата оплатысумма оплатыдата операциивид операции(абонемент/посещение/продажа товара...)клиент операции (один клиент может заплатить за другого) но в таблице оплат опять же надо расшифровывать за что оплата и получается представление данных почти с теми же столбцами только в другом порядке.. как то мне это не нравится может кто подскажет более удобный вариант представления начислений и оплат ? Или не парить мозг и первый вариант раздельного представления информации по сущностям он более логичен ? PS1 с хранением и расчетом проблем нет, все шустро и понятно , речь про юзабилити PS2 delphi6, DevExpress -- понимать что ты чего-то не знаешь - мудро, понимать что ты даже не знаешь, что чего-то не знаешь - печально, но это факт, который таки очень полезно понимать :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2010, 07:28 |
|
||
|
Минимизация представлений данных: чушь или благо дя юзера?
|
|||
|---|---|---|---|
|
#18+
LelikBolek, "остаток оплаты" смыла хранить нет, он же равен "сумма операции" - "сумма операции". Оплаты я бы тоже учитывал в журнале операций. Только суммы операций в них были бы с плюсом, а в остальных с минусом. Для услуг не хранил бы сумму оплаты. Вместо этого для оплаты в столбце код услуги указывал бы id услуги за которую платится. Клиента операции тоже можно не указывать в оплате, его можно определить по id услуги. В идеале вообще связи услуг и оплат вынести в отдельную таблицу, что бы одной оплатой можно было несколько услуг оплачивать, а также предоплату делать. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2010, 09:18 |
|
||
|
Минимизация представлений данных: чушь или благо дя юзера?
|
|||
|---|---|---|---|
|
#18+
kink, речь не про структуру БД, а про отображение на экране сумма оплаты, как и остатка конечно не хранится, а рассчитывается в селекте вопрос про удобство представления инфы юзеру !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2010, 09:24 |
|
||
|
Минимизация представлений данных: чушь или благо дя юзера?
|
|||
|---|---|---|---|
|
#18+
LelikBolek, что мешает обсудить этот вопрос непосредственно с пользователями? Предоставьте им 2 прототипа, пусть сами и выбирают, ведь это им с этим работать каждый день. Дублирование данных в представлениях вас не должно смущать, они ( представления ) для того и придуманы, чтобы представлять информацию в удобных пользователю разрезах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2010, 09:43 |
|
||
|
Минимизация представлений данных: чушь или благо дя юзера?
|
|||
|---|---|---|---|
|
#18+
kinkLelikBolek, "остаток оплаты" смыла хранить нет, он же равен "сумма операции" - "сумма операции". Есть. Со временем суммы операций станет считать накладно. А ещё есть такая хрень как деноминация, которая применяется на остаток лицевого счёта. kinkОплаты я бы тоже учитывал в журнале операций. Только суммы операций в них были бы с плюсом, а в остальных с минусом. Есть такая хрень как корректировка операции. Так хозяйственный смысл корректировки начисления в сторону уменьшения не совпадает со смыслом платежа (хотя обе операции увеличивают остаток на счёте) - например налоги с них по разному вычисляются и документальное обоснование разное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2010, 13:00 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=36731794&tid=1542625]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
186ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 502ms |
| 0 / 0 |
