Bankir.Ru
3 декабря, суббота 09:42

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

Идеальная коробочная АБС для маленьких банков

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

  • Идеальная коробочная АБС для маленьких банков

    Понимание идеала у всех, разумеется, разное...

    Платформа.
    Не с того, не с того начинать надо.
    MS-SQL 7 и выше сами знаете на чём и выше (цена и стоимость владения).
    Freeware пока вызывает сомнения. Или уже нет?

    Архитектура.
    Комбинация 2-ух и 3-ёхзвенной.
    Промежуточный слой для "докуметарной/проводочной машины" с открытым интерфейсом, разграничения прав и доступа, протоколирования, лицензирования...
    Прямой доступ к базе и/или её реплике для получения отчётности, анализа,
    о правах и доступе пускай дядя Билли с администратором заботятся.
    Разделение баз данных по функциональному назначению.
    "Наглядная", частично избыточная внутренняя структура баз в ущерб компактности.

    Рабочие места.
    Специализированные кросс-платформенные для различных операторов;
    виндовые для администрирования, отчётности.
    Открытый интерфейс для модулей получения обязательной (или другой извращённой) отчётности и/или внешние модули с открытым кодом.

    Политика ценообразования и лицензирования
    Открытая, прозрачная, неблокирующая.
    Возможно, плата за сопровождение, завязанная на публикуемую отчётность.
    Баланс интересов...

    Поддержка и сопровождение
    Коробочка - она и есть коробочка. Нормотворчество отслеживать, но поддержка специфики отдельных банков - за счёт открытости интерфейсов.

    Ой, сколько всего забыл!

  • #2
    VTB
    Freeware пока вызывает сомнения. Или уже нет?
    1. Freeware (это какие?...), Open Source (InterBase, PostgreSQL, что-то еще?)

    Если OpenSource, то они чаще всего вызывают сомнения у непрофессионалов. Для их грамотного и продуктивного применения (что вполне возможно!) надо нанимать людей, реально их знающих. Кстати, мой опыт сравнения Btrieve/PervasiveSQL c mySQL далеко не в пользу первого...
    М.Голованов

    Комментарий


    • #3
      mgolovanov
      Для их грамотного и продуктивного применения (что вполне возможно!) надо нанимать людей, реально их знающих.

      Вступает в противоречие с низкой стоимостью владения
      Видимо, ещё да!

      Комментарий


      • #4
        VTB
        Вступает в противоречие с низкой стоимостью владения
        Ха-ха. За много лет программирования я понял, что при решении некоей определенной задачи обычно бывает несколько примерно равноценных по затратам рациональных способов решения. Поэтому желающий сэкономить на Open Source - наивен. В итоге вы получите примерно те же затраты (если, конечно, все делаете правильно - сдуру можно и сами знаете чего). Просто дороже разработка и поддержка - дешевле лицензии и аппаратные средства. На MS SQL любая мартышка напишет - и будет работать, хоть и плохо... Но деньги и память жрать будет только так.
        М.Голованов

        Комментарий


        • #5
          mgolovanov
          желающий сэкономить на Open Source - наивен

          А разве я спорю?

          Комментарий


          • #6
            VTB
            На MS-SQL 7 в России АБСок - раз/два и обчелся... Если же что-то и выше сами знаете на чём и выше , то, видимо, Вы отвергаете Btrieve-Pervasive решения. До сих пор из "тяжеловесных" СУБД только "Ва-Банк Старт" провозглашался как коробочное решение.
            Впрочем (мое личное мнение), коробочные решения сегодня из "живых" и "растущих" банков никому не подходят.
            Да пребудет с Тобою Великая Сила! ©

            Комментарий


            • #7
              К_Маркелов

              Насчет "коробочных" согласен на 100%.
              Считаю "свой" (в смысле - тут работаю) банк "маленьким", но "живым"...

              Вот, выбрали БИСквит - в основном, за стабильную работоспособность в сочетании с возможностью "расковырять" все, что угодно. Правда, к чести своей могу сказать, что собственно выбор делали бухгалтеры с начальником кредитного отдела (в конкурентах были Банкир, Ва-банк и Диас 5НТ).
              /kiv

              Комментарий


              • #8
                mgolovanov

                Да, да, расскажите нам, пожалуйста, когда появились транзакции в mySQL. По-моему что-то около года назад?

                Комментарий


                • #9
                  old_oak
                  Да, да, расскажите нам, пожалуйста, когда появились транзакции в mySQL
                  Механизм двухфазной фиксации пакета обновлений (в просторечии транзакций) в mySQL появился недавно, по-моему, под давлением пользователей, привыкших к BEGIN/COMMIT/ROLLBACK. Ранее его не было по принципиальным соображениям некоторых ведущих разработчиков, полагавших (вполне резонно) что, во-первых, он нужен менее чем в 1% обращений к БД даже в OLTP системах, а во-вторых, есть другие, более эффективные способы обеспечения целостности БД (см., напр., http://www.mysql.com/doc/M/i/Missing_Transactions.html). Но для однообразия таки сделали.
                  М.Голованов

                  Комментарий


                  • #10
                    mgolovanov
                    Посмотрим на эти "эффективные" способы:

                    1) MySQL, in almost all cases, allows you to solve for potential problems by including simple checks before updates and by running simple scripts that check the databases for inconsistencies and automatically repair or warn if such occurs. Note that just by using the MySQL log or even adding one extra log, one can normally fix tables perfectly with no data integrity loss.

                    То есть нам предлагают эффективно написать свои скриптики, которые проверяют целостность БД, копаются в логе MySQL и восстанавливают, если что не так.

                    2) Moreover, fatal transactional updates can be rewritten to be atomic. In fact,we will go so far as to say that all integrity problems that transactions solve can be done with LOCK TABLES or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases.

                    Еще лучше - давайте лочить таблички направо и налево, скажем, табличку с остатками на счетах. Вот скорость-то возрастет!

                    Комментарий


                    • #11
                      old_oak
                      Посмотрим на эти "эффективные" способы
                      Сарказм пропускаю. Все остальное имеет смысл обсуждать лишь в контексте более или менее глубокого опыта работы с БД в многопользовательских системах.

                      Что касается необходимости что-то дописывать - мне кажется, этот труд с лихвой компенсировал стоимость лицензий коммерческих СУБД.
                      М.Голованов

                      Комментарий


                      • #12
                        mgolovanov
                        Представляю себе коробочную АБС - операционка FreeBSD, база данных - MySQL, написана на PHP
                        Только вот сколько будет желающих купить это?
                        Я умываю руки ...

                        Комментарий


                        • #13
                          Shamai
                          Представляю себе коробочную АБС
                          Я не представляю. Это средства совсем для других целей. А вот на Interbase - вполне. Которая вполне работоспособна и на FreeBSD. Как раз в моей текущей фирме есть продукт, писанный параллельно для Oracle и для Interbase. Разница только в деньгах за Oracle и некоторых "маленьких отличиях". Да, и в наворотах администрирования Oracle, которые под силу только админу с гонораром в тонну ам.р. То есть опять же деньги...
                          М.Голованов

                          Комментарий


                          • #14
                            mgolovanov

                            Просто я о том, что лучше не применять mySQL в АБС. Ее область применения - закачал один раз данные и делаешь 1000 выборок в секунду - например, каталог товаров. Вот где она покажет себя во всей красе. Приложения с большим количеством проверок перед транзакционными изменениями (например, дебет одного счета и кредит другого), в которых одни и те же данные меняют сотни пользователей, нуждаются в другой СУБД. В mySQL постраничный lock сделали хоть?

                            Комментарий

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

                            Свернуть

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

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