Извиняюсь за офф-топ, но уже несколько дней мучаюсь вопросом: почему разработчики ЦФТ используют связку child-таблиц с parent-таблицами через механизм коллекций (collection_id)? Не проще ли было бы их связать стандартно, через внешний ключ? Кроме возможности привязки одной child-таблицы к нескольким parent ничего в голову не приходит. Может кто подскажет, где зарыта собака?
Последний раз редактировалось: cap (Вт Апр 24, 2012 10:52), всего редактировалось 1 раз
Чт Апр 19, 2012 05:48 Re: Вопрос про collection_id
Полезность: 1
cap пишет:
Добрый день!
Извиняюсь за офф-топ, но уже несколько дней мучаюсь вопросом: почему разработчики ЦФТ используют связку child-таблиц с parent-таблицами через механизм коллекций (collection_id)? Не проще ли было бы их связать стандартно, через внешний ключ? Кроме возможности привязки одной child-таблицы к нескольким parent ничего в голову не приходит. Может кто подскажет, где зарыта собаку?
Есть операция, возвращающая задолженность по фактическим операциям.
Фактические операции могут быть привязаны как массивы к кредитам, депозитам, портфелям, межбанку, и т.д.
Бизнес-сущность одна. Обрабатываться все операции должны одинаково. И это удобно. Этого проще достичь, объявив одни и те же правила для всех.
Теперь посмотрим, что получится, если сделать N таблиц для факт.операций. Получается N операций, возвращающие задолженности для кредитов, депозитов, портфелю, межбанку, и т.д.
При этом каждый продукт будет считать, что таблица факт.операций относится к его подсистеме (и он будет прав), и может воротить в ней что душе угодно.
В результате имеем - кто в лес, кто по дрова.
Иметь N версий различного функционала гораздо затратнее.
Далее, представим себе, что нужно грохнуть все операции одного договора. Лучше - плановые операции, так как это имеет смысл при перестроении графика гашений.
Как это можно сделать в случае N таблиц? долго и муторно удалять записи из таблицы план.операций, в том числе в моменты, когда сервер загружен по самое не могу.
В случае с используемой в ЦФТ модели достаточно изменить реквизит владельца массива у договора, и все - бесхозные операции продолжают валяться в таблице, но уже ни к кому не относятся, и можно их грохать когда будет удобно.
Третий плюс: есть история плановых операций, есть актуальный график. При этом актуальный график должен быть доступен без дополнительного анализа. В случае с collection_id достаточно разместить все плановые операции в одной таблице, а у владельцев разместить в реквизит актуального графика значение collection_id группы плановых операций из истории плановых операций, соответствующих последнему их состоянию.
ИМХО, это очень умное, верное и годное решение - collection_id
Пт Июл 20, 2012 13:57 Re: Вопрос про collection_id
Полезность: Нет оценки
cap пишет:
Добрый день!
Извиняюсь за офф-топ, но уже несколько дней мучаюсь вопросом: почему разработчики ЦФТ используют связку child-таблиц с parent-таблицами через механизм коллекций (collection_id)? Не проще ли было бы их связать стандартно, через внешний ключ? Кроме возможности привязки одной child-таблицы к нескольким parent ничего в голову не приходит. Может кто подскажет, где зарыта собака?
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB
О проекте
Поиск
Отзывы
Регистрация
Вход
