Bankir.Ru
10 декабря, суббота 02:15

Объявление

Свернуть
Пока нет объявлений.

Пути развития АБС

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Пути развития АБС

    На сайтах разработчиков есть что то подобное, но там только видение конкретного производителя в связке со своими наработками. Разработчикам, как и банкам, тоже нет желания терять произведенные инвестиции.

    Интересно узнать Ваше мнение об архитектуре АБС, что должно представлять собой "ядро" насколько оно должно быть "стабильным". КАК должна быть реализована АБС.

    В принципе на эти вопросы есть ответы, но все они датированы второй половиной девяностых, когда была необходимость коренной перестройки АБС. А сейчас тишина и никаких видимых движений.

    Если будут конструктивные рассуждения, может кто из разработчиков что то возьмет на заметку.

  • #2
    2 roa:
    Если будут конструктивные рассуждения, может кто из разработчиков что то возьмет на заметку.
    Судя по этой фразе Вы думаете, что разработчики развивают свои АБС только из собственных соображений? Тогда позвольте Вас уверить, что это далеко не так. "Двигателем прогресса" в области АБС сегодня являются ЦБ и прочие контролирующие органы и сами коммерческие банки. По моим представлениям на долю удовлетворения их потребностей приходится 90 (если не больше) процентов нововведений и усовершенствований.
    А если Вы этой фразой подразумевали что-то типа "подскажем разработчикам как им разрабатывать АБС", то обратитесь к старой теме "Разработаем собственную АБС", где представители банков с жаром обсуждали разработку АБС собственными силами. Думаю из этой темы Вы подчерпнете всю необходимую информацию.

    Только заметьте, что лучше бы разработчикам брать на заметку не конструктивные рассуждения, а конструктивные выводы и предложения.

    Удачи,
    Константин [/I]

    Комментарий


    • #3
      В том то и дело что тема "старая", после этого обсуждения никаких новых тем все замерло на одном месте.
      Но ведь у каждого есть свое видение будущего "АБС" в широком смысле.[/QUOTE]

      Комментарий


      • #4
        Мое мнение, внутри АБС (только это не АБС) должна быть очень простой и поэтому очень надежной. Т.е., это максимум возможностей, в смысле надежности и производительности, используемой СУБД. Например:

        1. план счетов содержит справочник лицевых счетов, где одним из атрибутов являеться уникальный идентификатор (ну к примеру idnum). Кроме того, там конечно и много другой информации, но для обсуждения принципа это не важно.
        2. проводка (не документ, не операция, а элементарная проводка) содержит ссылку на счет дебет, ссылку на счет кредит, и набор сумм (типа в валюте в эквиваленте, по дебету, по кредиту)
        3. есть таблица остатков по лицевым счетам, где опять таки есть ссылка на уникальный номер лицевого счета, дата модификации и остатки по всем суммам, которые входят в проводку. У себя мы правда здесь же храним еще и обороты. Это удобно для дальнейшего удаления ненужной информации. В самом деле, зачем хранить остаток, если обороты в этот день равны нулю.

        Соединив эти три (всего три!) таблицы достаточно простым АПИ на сторед-процедурах (например) мы получаем простейшую, весьма производительную и высоконадежную систему почти бухгалтерского учета.
        Все остальное (что, правда и позволит назвать это АБС) является навеской на это место. Дополнительными справочниками, классификаторами и пр. ерундой.
        Кстати, буквально на днях закончил писать по этой технологии бухгалтерию для обычной фирмы (не кредитной организции), принцип на удивление подошел.

        Комментарий


        • #5
          AlexCH
          1. план счетов содержит справочник лицевых счетов, где одним из атрибутов являеться уникальный идентификатор (ну к примеру idnum).
          А зачем? Номер счета и есть его уникальный идентификатор в принципе Или Вы для скорости за счет исключения поиска по строковым полям?

          2. проводка (не документ, не операция, а элементарная проводка) содержит ссылку на счет дебет, ссылку на счет кредит, и набор сумм (типа в валюте в эквиваленте, по дебету, по кредиту)
          Тогда уж проще понизить все до полупроводки

          3. ... Это удобно для дальнейшего удаления ненужной информации. В самом деле, зачем хранить остаток, если обороты в этот день равны нулю.
          Если обороты в этот день равны нулю, зачем в эту таблицу вообще что-то по счету за этот день записывать, а потом удалять?

          Комментарий


          • #6
            vsv
            Номер счета и есть его уникальный идентификатор в принципе
            Ни к коем разе. И отнюдь не из-за скорости. Номера счетов можно повторно использовать по прошествии какого-то времени.

            Тогда уж проще понизить все до полупроводки
            Тогда будет сохранена возможность расхождения баланса. Я бы и сумму в валюте только одну оставил, во избежание. А внутри-то оно, в процедуре и так до полупроводки расписано, а как же иначе. Только интерфейс не позволяет оперировать с полупроводками.

            Если обороты в этот день равны нулю, зачем в эту таблицу вообще что-то по счету за этот день записывать, а потом удалять?
            Вот и я так думал. А когда это место у себя поправили, то от всех контролей наличия остатка сразу избавились. Главное при открытии (или переоткрытии счета) аккуратно остатки восстановить, а по закрытии проверить и удалить. А модификация при выполнении проводки

            update ostlicsch set sumost=sumost+sumprv where schet=schd and dat>=datprv
            update ostlicsch set sumost=sumost-sumprv where schet=schk and dat>=datprv

            ну и второй, который правит обороты

            update ostlicsch set obd=obd+sumprv where schet=schd abd dat=datprv
            update ostlicsch set obk=obk+sumprv where schet=schk abd dat=datprv

            Откат проводки аналогично, только знаки поменять.
            Вот собственно я вам кусочек реально работающего кода привел.

            Комментарий


            • #7
              AlexCH
              Номера счетов можно повторно использовать по прошествии какого-то времени.
              Логично

              Тогда будет сохранена возможность расхождения баланса.
              Она и так будет сохранена Если Вы храните при этом остатки и обороты - ну вот она и есть возможность
              Если же мы говорим о пользовательском интерфейсе, то, по хорошему, им то и проводки ИМХО как таковые не особо нужно видеть Есть документ, есть схема проводок настроенная под него 1 раз, и оно уже внутри согласно этой схемы разбивается А бух видит документ и имеет набор печатных форм с него Он весел и счастлив

              А когда это место у себя поправили, то от всех контролей наличия остатка сразу избавились
              С точки зрения простоты реализации - согласен
              Хотя так и так есть момент вставки остатков и оборотов за дату, вот и привязать его к первой проводке А удалять лишнее - сразу при откате проводки Ничего алгоритмически сложного в этом нет

              Комментарий


              • #8
                AlexCH
                Соединив эти три (всего три!) таблицы достаточно простым АПИ на сторед-процедурах (например) мы получаем простейшую, весьма производительную и высоконадежную систему почти бухгалтерского учета.

                Все это конечно замечательно, только нынешние АБС это далеко не просто системы бухгалтерского учета. И высокая производительность последнего не дает никаких гарантий быстрой и качественной работы всего остального.

                Да и предложенная схема отнюдь не так производительна и надежна как кажется. Представим, что с АБС работает не один а 1000 пользователей. Как будет отслеживаться целостность при их одновременной работе?
                А если все они активно вколачивают платежки (по одной в минуту) и все на корсчет в РКЦ. И естественно, что все эти платежки пытаются изменить остаток по этому самому корсчету. Сколько времени каждый из пользователей будет ожидать?

                Это с одной стороны. А с другой можно отметить следующее: такая простая организация бухучета позволит (в монопольном режиме) выполнять до 10 миллионов транзакций в час. Это кому-нибудь надо? Не лучше ли несколько "нагрузить" бухучет с тем, чтобы упростить и ускорить последующее получение отчетности и другие операции?

                Комментарий


                • #9
                  2vsv : Тогда уж проще понизить все до полупроводки

                  Неееет, только не это ! Искать в отчётах пару для полупроводки - занятие не для слабонервных. Да и по скорости сия операция сродни быстроте ползания умирающей улитки .
                  WBR, Александр Турчин

                  Комментарий


                  • #10
                    Посторонний
                    Я же и сказал, что это только основа для создания АБС.

                    Все это конечно замечательно, только нынешние АБС это далеко не просто системы бухгалтерского учета. И высокая производительность последнего не дает никаких гарантий быстрой и качественной работы всего остального.

                    Насчет целостности при любом кол-ве пользователей дальнейшие функции работают. Например перед выполнением того кода, который я привел, неплохо сделать блокировки таблицы остатков. Что и делается у нас, только маленько раньше. А за целостностью в любой нормальной субд следит сама субд. Например по отсутствующему счету она не даст сделать проводку, поскольку ссылочная целостность не будет выполняться.
                    А в обсуждении, я думал, мы рассуждаем о ядре АБС, т.е. фактически о системе хранения остатков и проводок. Я могу и маленько выше подняться и рассуждать об открытии лицевых счетов, или поверках при закрытии операционного дня.

                    А насчет скорости не согласен - если это место у вас написано неверно, то вся работа системы будет идти слишком медленно для комфортной работы персонала.

                    Комментарий


                    • #11
                      AlexCH
                      Например перед выполнением того кода, который я привел, неплохо сделать блокировки таблицы остатков.
                      Блокировку таблицы можно делать если работает два-три пользователя, а при большом количестве пользователей с блокировками надо быть о-о-очень аккуратным.
                      А насчет скорости не согласен - если это место у вас написано неверно, то вся работа системы будет идти слишком медленно для комфортной работы персонала.
                      Естественно, если ядро не позволяет делать больше одной проводки в минуту, то любая оптимизация остального кода ни к чему не приведет. Но есть ведь и разумные потребности. И 10 миллионов транзакций (даже в день) для большинства банков совершенно ни к чему.

                      И собственно по существу вопроса
                      На мой взгляд ядро АБС должно обеспечивать:
                      1. Распределенную работу пользователей.
                      Банки активно объединяются, развивают филиальную сеть и средства для оперативного отслеживания состояния всего банка (холдинга и т.п.) требуются все больше и больше.
                      Понятно, что нынешнее состояние связи не позволяет работать на единой БД (да и БД не потянет), а вот средства для быстрого и автоматического согласования данных должны быть.

                      2. Механизмы для небухгалтерского (и даже небанковского учета).
                      Спрос на аналитические системы постоянно растет, появляются новые и новые методики, но ни одна из методик не работает, если не обеспечить первичный сбор необходимых данных. Если АБС умеет только отслеживать остатки и обороты по счетам, то никакой разумной аналитики из этого не слепишь.

                      3. Высокую адаптивность.
                      Причем это требование относится не только к "промышленным" АБС, адаптивность которых нужна для удовлетворения требований заказчика при очередном внедрении, но и для собственных. К сожалению (или для нас автоматизаторов к счастью - без работы не останемся) ЦБ регулярно модифицирует правила игры. Постоянно появляются новые инструкции требования и т.п. Сегодня одно поля в платежку добавим, завтра другое и т.п. Система должна уметь быстро реагировать на такие изменения. Этого можно добиться либо реализовав всю систему на базе конструктора, либо обеспечив прозрачность исходного кода.

                      Комментарий


                      • #12
                        Во блин, расписался. И чего это меня на философию потянуло?

                        Комментарий


                        • #13
                          Александр_Турчин
                          Неееет, только не это !
                          Ага, испугались На самом деле если тупо следовать ЦБ-шным инструкциям - идея полупровродки как-то сама появляется

                          Посторонний
                          Система должна уметь быстро реагировать на такие изменения. Этого можно добиться либо реализовав всю систему на базе конструктора, либо обеспечив прозрачность исходного кода.
                          Согласен

                          Комментарий


                          • #14
                            vsv Ага, испугались

                            Не испугались, а наелись...

                            Комментарий


                            • #15
                              Pif
                              Не испугались, а наелись...
                              Это про Афину что ли? Тут конечно могу согласиться: бухгалтерское ядро в Афине оказалось не готово к выходу 360-у. А если вспомнить старые инструкции, то полупроводки в отчетности совсем не запрещались.
                              Все это как раз к вопросу о том, что бухгалтерское ядро должно быть очень простым.
                              Если всегда будут двусторонние проводки, то ряд вещей (выписки например) не очень удобно получать. А если односторонние, то бухжурнал тяжело делать. Вот и выходит, что хранить надо и те и другие или еще как-то "извращаться". И "простое, надежное" ядро становится все сложнее и сложнее.

                              Комментарий


                              • #16
                                AlexCH 1. план счетов содержит справочник лицевых счетов, где одним из атрибутов являеться уникальный идентификатор (ну к примеру idnum). Кроме того, там конечно и много другой информации, но для обсуждения принципа это не важно.
                                2. проводка (не документ, не операция, а элементарная проводка) содержит ссылку на счет дебет, ссылку на счет кредит, и набор сумм (типа в валюте в эквиваленте, по дебету, по кредиту)
                                3. есть таблица остатков по лицевым счетам, где опять таки есть ссылка на уникальный номер лицевого счета, дата модификации и остатки по всем суммам, которые входят в проводку.
                                .................
                                Например перед выполнением того кода, который я привел, неплохо сделать блокировки таблицы остатков.

                                А на хрена все это создавать ведь это было уже и даже есть еще
                                Называется "Тульский опердень" версия 2.1, год сами знаете какой.

                                Комментарий


                                • #17
                                  Посторонний
                                  На мой взгляд ядро АБС должно обеспечивать:
                                  ...
                                  2. Механизмы для небухгалтерского (и даже небанковского учета).


                                  И на этом месте плавно скатываемся в тред "Как (и надо ли) слить OLTP и OLAP в один флакон".

                                  Комментарий


                                  • #18
                                    2Abo : И на этом месте плавно скатываемся в тред "Как (и надо ли) слить OLTP и OLAP в один флакон".

                                    Имхо реалии российской банковской жизни (по крайней мере в отдельно взятом нашем банке) показывают, что несколько капель OLAP (или даже большая ложка) в флаконе с OLTP жизненно необходимы. Теория - это хорошо, но вот на практике всё несколько усложняется (покажите мне, к примеру, АБС с полностью нормализованной БД).
                                    WBR, Александр Турчин

                                    Комментарий


                                    • #19
                                      Не, господа, таких АБС нам не нада!!!
                                      Далее - ИМХО, сугубо.

                                      Банк - организация, работающая с реальными лицами (физическими и юридическими). Вся бухгалтерия порождается от общения с другими субъектами деятельности. Так вот в ядре системы должен стоять - КЛИЕНТ или субъект, т.е. нам нужен CRM + гибкий настраиваемый документооборот (не только финансовый) + учетные категории (в т.ч. счета, отчетные символы...).
                                      Все операции должны "плясать" от клиента, договоров с ним.
                                      "От проводок" уже ни как. Либо проводка должна быть универсальной структурой, чтобы в ней хранить информацию о сделке, о договоре. Но, согласитесь, универсальность в данном аспекте невозможна. Бухгалтерская отчетность - не цель современной АБС, это достаточно простая задача если есть все учетные составляющие. Она, АБС, должна служить для управления банком, выдавая "на гора" аналитику.
                                      Согласен с vsv, что в большенстве своем операционисты и еще куча другого народа не должны видеть проводки вааще, тем более что-то менять.
                                      Жить надо так, чтоб тебя помнили сволочи!

                                      Комментарий


                                      • #20
                                        alanf
                                        Вся бухгалтерия порождается от общения с другими субъектами деятельности.
                                        Все операции должны "плясать" от клиента, договоров с ним.
                                        Бухгалтерская отчетность - не цель современной АБС, это достаточно простая задача если есть все учетные составляющие.
                                        АБС, должна служить для управления банком, выдавая "на гора" аналитику.

                                        Позвольте, так все это чистой воды OLAP. Вот только практика показывает, что не слишком этот зверь востребован в кругах выше начальника отдела автоматизации не очень крупных банков .
                                        А что делать с такими двумя проблемками:
                                        1. Пока еще (до введения ЦБ новых норм учета) учет из OLAP построить, и правда, можно запросто. Но вот попробуйте отчетность для ЦБ сделать. О, вот тут уже надо голову поломать и стоить такой проект будет уже очень недешево.
                                        2. А скажите, в каком банке персонал готов к такой "АБС"? У кого в банке (среднем или небольшом) руководитель регулярно просматривает отчеты о ликвидности и себестоимости своих банковских продуктов, а операционные работники в состоянии верно проставить реквизиты аналитического учета в документ клиента?
                                        Ведь не секрет, что для построения грамотного управленческого учета необходимо вести детальную информацию по каждому объекту, будь то клиент или операция. И разговоры о том, что OLAP надо только поставить, а потом сидеть и наслаждаться видами ситуации в банке в разных плоскостях и срезах - не более чем миф.

                                        Комментарий


                                        • #21
                                          м-да... вот закружишься на денёк... как лихо новичок аксакалов на философию "раскрутил"... Зарегистрирован: 07-04-2003
                                          Откуда:
                                          Сообщений: 2

                                          roa, увы, не уточнил: его интересует вопрос развития конкретной АБС со стороны конкретного Банка? Или - той же базовой АБС со стороны конкретного разработчика?
                                          При уточнении вопроса философия ответов должна быть различной!!!
                                          Уважаемый roa! Уточните, пожалуйста...
                                          Да пребудет с Тобою Великая Сила! ©

                                          Комментарий


                                          • #22
                                            Abo
                                            И на этом месте плавно скатываемся в тред "Как (и надо ли) слить OLTP и OLAP в один флакон".
                                            Нет. Я говорил об учете, а не об анализе. Как я написал, для обеспечения аналитических методик необходим сбор первичных данных. И одних остатков по счетам далеко недостаточно. Вот АБС и должна обеспечить сбор таких данных небухгалтерского характера, а их консолидация, анализ и т.п. задача OLAP системы.
                                            alanf
                                            Бухгалтерская отчетность - не цель современной АБС.
                                            Круто! А чья же это цель тогда? Главбуха? Пусть как хочет так и корячится, хоть на бумажке, хоть в ехеле...
                                            В том-то и состоит отличие АБС от какого-нибудь САПРА, что бухучет в ней занимает стержневое положение. Но и от тульского опердня АБС отличается тем, что в ней кроме бухучета еще и другие вещи есть.

                                            Комментарий


                                            • #23
                                              маркелову
                                              Уважаемый roa! Уточните, пожалуйста...
                                              Если бы интересовали частности, то не сомневайтесь так бы и спросил.
                                              м-да... вот закружишься на денёк... как лихо новичок аксакалов на философию "раскрутил"...
                                              значит наболело, говорю же давно никто не поднимал вопрос.

                                              [/QUOTE][/B]

                                              Комментарий


                                              • #24
                                                Обложили все! А напрасно. Я ж про ядро написал. Его никто никогда не видит и не увидит. Я писал про механизм, лежащий в основе именно бухгалтерского учета. Все остальное конечно тоже есть, но, согласитесь, обсуждать систему в целом в данном форуме (и по заданному вопросу) как то не очень...
                                                Конечно дальше у нас идут документы, которые собственно при проводке по балансу и порождают проводки. Проводки у нас любой может видеть (все таки банк - это большая бухгалтерия), но, естественно изменять из можно только посредством работы с документами.
                                                Еще дальще у нас идут операции. Типа переоценки, открытия валютного опердня и пр. При реализации которых порождается множество документов.
                                                Вся реализация в виде сторед-процедур внутри базы зашита. Я могу, конечно, выкладывать кусочками реализацию, но ее уже под 1500 штук. В том числе и то, что к ядру никакого отношения не имеет, например подготовка данных для печатных форм.

                                                Комментарий


                                                • #25
                                                  Посторонний
                                                  Блокировку таблицы можно делать если работает два-три пользователя, а при большом количестве пользователей с блокировками надо быть о-о-очень аккуратным.

                                                  При описанном мной механизме, блокировка таблицы выполняется на время, не превышающее время ожидания выполнения транзакции. Поэтому при нашей работе - 3000-4000 проводок в день никто из работающих дискомфорта не ощущает. Более того, даже работающие по медленному спутниковому каналу не жалуются. Пиковые загрузки в 10000 проводок в последние дни квартала (месяца) так же не приводят к сбоям в работе. Иногда проскакивает сообщение об ошибке, но редко.

                                                  Комментарий


                                                  • #26
                                                    По предлагаемому принципу строились системы в конце 80-начале 90х годов прошлого века. Сейчас бух. учет уже не является основопологающей функцией АБС. Ядро АБС должно строиться на основе сделок, а не проводок.

                                                    Комментарий


                                                    • #27
                                                      Это наверное уже идеология АБС, плясать от сделок и прочих документов.
                                                      На простейшем уровне все таки надо оперировать проводками.

                                                      Комментарий


                                                      • #28
                                                        AlexCH
                                                        При описанном мной механизме, блокировка таблицы выполняется на время, не превышающее время ожидания выполнения транзакции. Поэтому при нашей работе - 3000-4000 проводок в день никто из работающих дискомфорта не ощущает.
                                                        Ну транзакция не такая короткая как кажется. Ведь сначала надо проверить, что операция возможна, то есть деньги у клиента на счете есть, а затем собственно выполнить транзакцию. Остаток по счету должен быть заблокирован уже перед проверкой (дабы никто другой не поменял его после проверки), то есть блокировка становится не столь уж короткой.
                                                        Да для небольшого банка все это вполне приемлемо. Но если документооброт придлижается к 100 тысячам в час, то проблемы с блокировками выползают на первый план. Просто получается, что производительность крутого многопроцессорного сервка почти не превышает производительности однопроцессорной машины.

                                                        Комментарий


                                                        • #29
                                                          Посторонний
                                                          Круто! А чья же это цель тогда? Главбуха?
                                                          Цель АБС - управление банком. Я же напостил, что бухучет не очень сложная задача. А проводки действительно нужны Главбуху и его команде. Согласитесь, все остальные работают с операциями, а операция - это совокупность проводок, в общем виде.
                                                          Операции банка - практически инвариантны, т.е. если АБС будет нести механизм создания проводок от операций, при этом легко настраиваемый, то построить бухгалтерию по документам-сделкам - простая задача. А девочке Маше из кассы нужна операция "Покупка/продажа/взнос/выдача", но ни как не проводки.

                                                          Cost
                                                          А скажите, в каком банке персонал готов к такой "АБС"? У кого в банке (среднем или небольшом) руководитель регулярно просматривает отчеты о ликвидности и себестоимости своих банковских продуктов, а операционные работники в состоянии верно проставить реквизиты аналитического учета в документ клиента?
                                                          Ведь не секрет, что для построения грамотного управленческого учета необходимо вести детальную информацию по каждому объекту, будь то клиент или операция. И разговоры о том, что OLAP надо только поставить, а потом сидеть и наслаждаться видами ситуации в банке в разных плоскостях и срезах - не более чем миф.


                                                          Это не миф, это реальность. Именно руководителям среднего или небольшого банка нужна эта информация - ликвидность, рентабельность того или иного продукта и т.д. и т.п. Я даже знаю однин такой банк точно.
                                                          Операционные работники и не должны этого делать. Операционистка Катя должна уже пользоваться введенными данными о клиенте, о его договорах, о возможных операциях по договорам, вбивая операцию под названием "Перевод средств". А вот есть человек под названием манагер клиента, кредитный инспектор и куча другого ответственного народу, которому аналитика ох как нужна. И этот люд будет вбивать любую информацию, чтобы потом при нажатии на одну красную кнопку получить все отчеты, а из флоповода чтобы зряплата полезла. А если кто-то

                                                          Зачем ходить далеко, в глубь своих мечтаний. Например: возьмем нашу многострадальную девочку Катю, которая вбивая платежку проверяет код КНФ (она или другие уполномоченные люди). Ей это надо? В принципе - нет. Однако, а ежели ф.661 не посчитается, а если банк получателя завернет документ. Кому будет плохо? - КАТЕ!!! Она это понимает и добросовестно исполняет свои обязанности. Или кассир? Зачем ей кассовые символы (это же аналитика) балансовые, не дай Бог забалансовые? Да чтобы формы 20х бухгалтерия считала.

                                                          roa
                                                          На простейшем уровне все таки надо оперировать проводками
                                                          Кто сказал, что это простейший уровень? Для кого? Человеки придумали языки программирования высокого и среднего уровня потому, что это ближе к человеческому - всякие там printf, while, for. Хотя есть низкий уровень asm, или вообще сразу в бин. знаю человека который на asm под винды писал . Так вод проводки - это самый нижний уровень - чтобы сделать операцию такую-то нужно дебетовать такой-то счет, кредитовать другой, и это в главе А, плюс проводка по главе В в такой-то корреспонденции, а и чуть не забыл, нужно еще одну проводку по главе Налогового Учета, но последнюю нужно разбить на суммы, равномерно приходящиеся на отчетные периоды, и не забыть их потом из планируемых или отложенных провести. Катю жалко!
                                                          Жить надо так, чтоб тебя помнили сволочи!

                                                          Комментарий


                                                          • #30
                                                            Александр_Турчин несколько капель OLAP (или даже большая ложка) в флаконе с OLTP жизненно необходимы

                                                            Да-да, я об этом же, о реалиях.

                                                            Посторонний

                                                            Чем больше АБС нагружается сбором таких данных небухгалтерского характера, тем больше она становится инструментом оперативной аналитики, тем больше она должна уметь OLAP. В частности, уметь консолидировать из разных источников всю эту небухгалтерскую (и даже небанковскую) информацию.
                                                            Хорошо, конечно, волевым решением провести черту: отсель - учёт, досель - аналитика. Тогда что ж такое АБС? Хранилище данных или машина транзакций?

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X