logo
logo
Суммируя [Artem Fedorov 17/01/2003 04:41]
Итак, возражения понятны. Разберем по полочкам. Я насчитал их три:
 
1) Сумма родительской статьи равна сумме дочерних статей.
Обходной путь найден в том, чтобы создавать автоматическую операцию, корректирующую свое значение.
 
2) Дочерние записи должны иметь любые статьи
Обходной путь -- создать родительскую статью "Все статьи расхода". Или пустую, что то же самое в данном контексте.
 
3) Дочерние записи должны иметь любые статьи, НО родительская запись тоже должна иметь свою статью, не являющуюся родительской для статей дочерних записей
Вот тут решение не было найдено. Вся логика моих соображений противоречит тому факту, что у родительской записи своя статья, а у дочерних операций статьи совершенно из другой ветви, т.е. у них нет связи с родительской операцией. Остается решить, такой ли уж важный это постулат (несвязанность родительских и дочерних). Можно, конечно , разрешить делать что угодно, в том числе можно будет пользоваться и моим подходом. Но! Не тот ли это случай, когда вседозволенность идет во вред? Есть ли РЕАЛЬНАЯ потребность в том, чтобы родительская операция имела свою статью (не пустое поле!), а дочерние операции -- совершенно другие. Если родительская операция имеет в поле статьи пустое поле (или "все статьи расходов"), то это "не так эффективно" (с) Dervish. Перефразируя, можно сказать , что когда родительская операция имеет свою статью, а дети -- другие (статьи не из той же ветки, что и родительская статья, а совершенно из другой!), то это "еще менее эффективно". Вопросы:
о А как пользователь узнает, что эффективнее, если сама архитектура программы ему это не объяснит?
o Стоит ли давать в пользователю инструмент, которым можно неправильно пользоватся, при этом не поставив "предохранители"?
o Какая же реальная, практическая польза от родительских операций, которые не связаны с дочерними по статьям? Желательно пример их жизни.
 
Dervish: В общем, понятно, но теперь, пожалуй, это надо осмыслить. Спасибо.