Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей

    Firebird является очень популярной открытой СУБД в России, и, несмотря на отсутствие шумных маркетинговых акций, используется в большом количестве ответственных систем, особенно в медицинских и государственных системах автоматизации.

    Размер БД и количество активных пользователей в таких системах обычно достаточно большие, поэтому в этой статье я расскажу об опыте оптимизации настроек Firebird и Linux, основываясь на конкретных примерах больших БД Firebird в компаниях БудьЗдоров (Ингосстрах), АльфаЗдрав, и затрону опыт других компаний по оптимизации Firebird+Linux.

    Давайте подробнее познакомимся с предметом оптимизации — СУБД Firebird 3.0.5 (с расширениями HQbird), обслуживает БД размером 691Гб (на текущий момент) с ежедневными 1000-1100 пользователями, работает на Linux CentOS 7, сервер — железный HP DL380. Для БД настроена репликация на резервный сервер (вопрос о репликации вне рамок этой статьи).

    СУБД обслуживает медицинскую информационную систему Инфоклиника (производства российской компании Smart Delta Systems), которая является одной из самых популярных медицинских информационных систем в России.

    Давайте взглянем на подробности (скриншоты далее взяты из HQbird) работы этой базы данных:

    Данные интенсивно вставляются в БД — ежедневный прирост около 0.4 — 0.5 Гб



    1000-1100 соединений это обычная дневная нагрузка:



    Несмотря на интенсивный рост и активную работу, база данных не содержит сколько-нибудь значительного количества мусорных версий записей — как благодаря приложениям, написанным с хорошим знанием многоверсионной архитектуры, так и благодаря адекватно настроенной сборке мусора:



    Маркеры транзакций в «зеленой» зоне:



    Кстати, обратите внимание, что данные в БД — строковые, блобы присутствуют, но их мало — всего 10Гб из 690Гб общего размера.

    Характер нагрузки на БД смешанный, 75% операций чтения и 25% записи:



    Железо


    Сервер, который обслуживает эту систему, неплохой, но далеко не топовый:

    HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT
    320Gb RAM, 4 network cards

    Дисковая подсистема состоит из двух частей: локальный диск на 745Gb и двойной 2 fibre-channel connection к SAN, с разделом на 1.8Тб.

    Операционная система


    Используется CentOS 7, версия ядра:

    Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019
    

    На логичный вопрос, почему не используется самое современное ядро и CentOS 8, ответ тоже логичный — миграция ответственных систем происходит только после выпуска нескольких минорных релизов и тщательного тестирования — это один из тех случаев, когда известный баг лучше двух неизвестных.

    Однако, надо отметить, что до 2017 года система работала на CentOS 6.x, и после миграции было отмечено значительное улучшение показателей производительности.

    Настройка Linux


    Абсолютно необходимая настройка Linux для Firebird


    Есть 2 параметра, которые нужно обязательно увеличить на всех серверах Linux, где работает Firebird — число виртуальных областей памяти (virtual memory areas, VMA) и число открытых файлов для процесса Firebird.

    1. VMA

    Число VMA по умолчанию 64K, его необходимо увеличить в 4 раза, для этого в sysctl.conf надо добавить строку

    vm.max_map_count=262144

    Чтобы проверить текущее значение, используйте команду

    sysctl vm.max_map_count

    2. Max Open Files

    На каждое соединение к БД Firebird открывает до 20 описателей (файловых хэндлов) включительно (учитывая тот факт, что в Linux все ресурсы выглядят как файлы), поэтому максимальное количество открытых файлов по умолчанию (обычно 4096) может очень быстро исчерпаться.

    Чтобы проверить доступное количество файлов для Firebird, лучше всего посмотреть лимиты исполняемого файла Firebird:

    cat /proc/$(pgrep firebird)/limits

    где проверить значение для Max Open Files и увеличить их при необходимости.

    Чтобы увеличить параметр Max Open Files для Firebird, в файл firebird-superserver.service в секцию [service] мы добавили строку:

    LimitNOFILE=49999

    Опциональная настройка Linux


    На этом сервере мы также сделали следующие настройки

    1. Уменьшили swapiness

    Так как сервер является выделенным эксклюзивно для СУБД Firebird, и мы желаем эффективно использовать RAM под кэш СУБД и кэш файлов операционной системы, то уменьшаем swapiness c дефолтных 60% до 10%, для этого в sysctl.conf добавили

    vm.swappiness=10

    2. Увеличили минимальный зарезервированный размер памяти для специальных процессов ОС

    vm.min_free_kbytes=1048576

    т. е. 1Гб памяти. Эта настройка косвенно влияет на дефрагментацию памяти.

    Обратите внимание, что эта настройка индивидуальна — с учетом того, что у нас 320Гб RAM, 1Гб это не так уж и много, но в случае небольшого количества памяти (например, 32Гб), 1Гб мог бы быть перебором.

    3. Уменьшили keepalive

    Firebird полагается на keepalive интервалы, чтобы проверять состояние соединения, и по умолчанию значение keepalive может быть очень большим. Ограничивая его до 300 секунд, мы избавляемся от зависших соединений

    net.ipv4.tcp_keepalive_time=300
    net.ipv4.tcp_keepalive_probes=5
    net.ipv4.tcp_keepalive_intvl=15

    Еще больше тюнинга Linux


    Почему мы ограничились таким небольшим количество настроек Linux?

    Во-первых, мы придерживаемся консервативного подхода к тюнингу серверов с Linux (который становится все лучше и лучше с каждой новой версией), во-вторых, эта база данных Firebird не является ни экстремально большой, ни самой нагруженной, и Linux с указанными настройками справляется со своими задачами.

    Конечно, существует еще несколько настроек, которые можно использовать для оптимизации работы Firebird на Linux — например, ряд интересных вещей был представлен в презентации о 3 Тб базе данных Firebird (РедБаза) в Федеральной Службе Приставов.

    Настройка Firebird


    Конфигурационные файлы коммьюнити дистрибутива Firebird с firebirdsql.org настроены очень консервативно, и на мало-мальски мощном сервере необходимо изменять конфигурационные файлы, а также тщательно выбирать используемую архитектуру (в Firebird 3.0 существует 2 вида подключения: Embedded и NetworkServer, и 3 вида архитектур: SuperServer, SuperClassic, Classic).
    Также, необходимо использовать настройки для каждой БД — т.е. помещать критические настройки в databases.conf, с привязкой к конкретной базе данных.

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

    Ниже приведены конфигурационные файлы (только значения, относящиеся к производительности):

    firebird.conf — конфигурационный файл для всех БД на сервере

    DefaultDbCachePages = 50K    	# pages 
    FileSystemCacheThreshold = 300K  # pages 
    TempBlockSize = 2M			# bytes 
    TempCacheLimit = 20480M		# bytes 
    LockMemSize = 30M			# bytes 
    LockHashSlots = 30011		
    WireCompression = true 
    ServerMode = Super 
    ExtConnPoolSize = 500		 # HQBird
    ExtConnPoolLifeTime = 14200	 # HQBird  
    SortDataStorageThreshold = 8192 	 #HQbird reports queries

    С точки зрения производительности, ключевыми параметрами здесь являются следующие:

    1. DefaultDbCachePages = 50K # измеряется в страницах, на БД, при странице 16К = 0.8Gb

    Размер страничного кэша DefaultDbCachePages в firebird.conf специально установлен по умолчанию в 800Mb — для того, чтобы случайно затесавшаяся на сервере тестовая БД не попыталась занять огромное количество оперативной памяти.

    2. FileSystemCacheThreshold = 300K # pages

    Важно устанавливать этот параметр в значение большее, чем DefaultDBCachePages, чтобы разрешить использование файлового кэша ОС.

    3. TempCacheLimit = 20480M # bytes

    Это параметр устанавливает размер памяти для запросов с сортировками (и некоторыми другими операциями), и является индивидуальным для каждой системы.
    В результате мониторинга размеров сортировок мы выяснили, что 20Гб является оптимальным для данной БД.

    4. LockMemSize и LockHashSlots — параметры таблицы блокировок

    Эти параметры определяют начальный размер таблицы блокировок и количество слотов для вычисления хэш функции.

    5. WireCompression=True

    Настройка сжимает трафик между клиентами и серверов, особенно это полезно при интенсивных Execute Statement On External, которые выполняет клиентское приложение.

    Остальные параметры описаны в самом firebird.conf и сопутствующей документации Firebird и HQbird.

    Наиболее важные настройки мы вынесли в databases.conf, с точным указанием БД

    database1 = /data/database1.fdb {
    DefaultDbCachePages = 14080K  # 16K pages, 220 GB 
    FileSystemCacheThreshold = 15361K 
    TempSpaceCacheThreshold=2G  #HQbird only, track big sorts
    LockHashSlots = 40099 
    LockMemSize = 50M 
    }

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

    Для Firebird 3.0 c архитектурой SuperServer существует два подхода — консервативный, который используется на серверах с небольшим количеством оперативной памяти (до 32Гб включительно), который заключается в том, чтобы выделять под страничный кэш не более 25% RAM, и в остальном полагаться на файловый операционной системы, и тонкая настройка, когда мы точно определяем оптимальный размер для сортировок, выделяем определенный размер памяти для ядра ОС, резервируем определенный объем памяти для массивных файловых операций (например, резервное копирование), и остаток выделяем на страничный кэш.

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

    Типичные ошибки в настройке Firebird


    К типичным ошибкам относятся следующие:

    1) Явно указанный на странице заголовка БД размер страничного кэша, который переопределяет значения, указанные в firebird.conf и databases.conf.

    Особенно часто эта ошибка возникает при смене архитектуры с Classic/SuperClassic на SuperServer — если при явно указанном небольшом (500-2000 страниц) размере кэша на соединение Classic/SuperClassic работают нормально, то для SuperServer необходим гораздо больший кэш.
    Чтобы проверить, выполните команду

    gstat -h databasepathname

    и проверьте значение Page Buffers — оно должно быть равно 0, тогда Firebird будет использовать значения из databases.conf или firebird.conf.

    Для сброса установки страничного кэша на заголовочной странице выполните команду

    gfix -buff 0 databasepathname

    2) При увеличении страничного кэша забывают увеличить FileSystemCacheThreshold, что ведет к отключению файлового кэша, что снижает производительность.

    3) Использование размера страницы БД по умолчанию (4096 или 8192), в то время как для больших БД необходимо использовать 16К.

    Заключение


    В целом, 1000+ пользователей Firebird на железе, соответствующем нагрузке, настроенном Linux и сконфигурированном Firebird, работают без проблем. На данном сервере по производительности есть запас, который был протестирован в пиках нагрузки до 1500-1800 пользователей.

    Среди Linux-дистрибутивов для БД Firebird c подобной нагрузкой наиболее популярен CentOS 7, рекомендуемая версия — Firebird 3.0.

    Если есть вопросы, буду рад ответить в комментариях, или по email ak@ibase.ru.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      –4

      Кто-то до сих пор использует это гумно?
      О боже!

        +8
        Ну как сказать, кто — вот Вы, после бессонной ночи отладки Ангуляра, идете во Вкусвилл, а там Firebird внутри POS Frontol-а — отвратительно! Заказчик прислал бабки за вебсайт, идете смотреть курс бакса на Мосбирже, а там тоже Firebird — ужас-ужас! Приставы списали деньги за неоплаченный штраф — и там ведь Firebird, зараза (а до того — и в компьютере у мирового судьи). От таких переживаний плохеет, идете в аптеку купить витаминов — а там тройной удар — производитель витаминов Фармстандрт, аптечные дистрибуторы и сама аптека тоже имеет POS на Firebird! В частные больницы лучше не соваться, это уже понятно из статьи, в государственных да — MSSQL, госуслуги, можно попробовать. В общем, от всего этого Вы расстраиваетесь, решаете покинуть #этустрану, берете билет на Аэроэскпресс — ааа! Опять жар-птица! Добравшись до аэропорта, садитесь в лайнер Аэрофлота, но и там работает эта клятая СУБД… И наконец, взлетев на Боинге — осознаете, что Боинг то тоже использует Firebird.
          +2
          А можете написать, почему используют именно Firebird? Стабильность, легкость? Думаю, это будет полезно и для комментария выше, и для остальных.
          Спасибо
            0
            Могу вам как дилер рассказать тысяча и одну гениальную имплементацию Firebird-а в Rkeeper
              0
              А мы сами про rkeeper много чего знаем — нам довольно постоянно присылают БД на починку с «серверов» из ресторанов и кафе, причем часто это такие сервера, которые с 2003 не пылесосились, и «вдруг» сломались. Сложно представить себе любую другую СУБД, которая выжила бы 10-15 лет в подсобке на IDE диске, между посудомойкой и духовкой, без УПСов и ECC RAM. Но почему разработчики rkeeper не могут сделать бат файл из одной строки, который бы бэкапил их БДшки хоть куда нибудь, я понять не могу, но СУБД то тут точно не причем, верно? :)
                0

                А вот тут начинается очень интересная политика, на самом деле. Сам кипер делает бэкапы, причём так часто что некоторые клиенты просто офигевают с объёмов бэкапов, а sql уже считается, по крайней мере в глазах дилера, обязанностью клиента. И опять же, не от красивой жизни вся эта чернуха происходит — редкий клиент выделяет больше 2-5% бюджета на айти структуру. Вот и получаются "решения побюджетнее".

            0

            А что исподьзуете Вы? Не зависимо от ответа, всегда найдется индивидум, который напишет комментарий в роде вашего: ОМГ, кто использует это…
            На всевозможных форумах, посвящёных базам данных, регулярно возникают холивары по поводу выбора СУБД для проекта. И заканчиваются они всегда абсолютно ничем. Потому, что нет однознчного ответа.

              0
              Вполне рабочий инструмент. К тому же бесплатный. Для многих клиентов стоимость набора лицензий очень критична. У многих такое количество унаследованного кода, что переход на другую СУБД, при не очевидных для бизнеса преимуществах, не имеет никакого экономического смысла. А речь в статье, как я понимаю, не о новых проектах.
              Живи Firebird! :))
                +1

                А позвольте узнать, что не так с fb? Раз вы так резко высказываетесь, возможно у вас есть список конкретных претензий?
                У меня за момент интеграции pos-систем(2года, более 100 новых точек) всего раз приходилось ехать и "поднимать" кассу одной строкой фикса бд.
                Может у вас есть более интересный опыт?

                  0
                  имхо там все не так. начиная с отсутствия базовых вещей, типа партиций и лога транзакций, заканчивая мутноватый бизнес на горемычных пользователях. с тем самым «нам довольно постоянно присылают БД на починку». по мне это некрасиво не сделать полноценный лог, но устроить бизнес на починках.
                  кроме этого у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения. без лога транзакций фб вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.
                    0
                    у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения.

                    Тогда от PostgreSQL вы вообще бежите как черт от ладана?


                    вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.

                    1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу, но пишут. Просто fsync делают только на log.
                    2) зато файербёрду не нужно прокручивать лог на старте в случае чего, не нужно иметь две сущности (датафайлы и лог). Если они смогли сделать так, что rps не сильно страдает, то чем же это плохо?
                    Конечно rps будет страдать. Но:
                    a) во многих охвученных применениях база локальна небольшому числу пользователей, а значит rps заведомо небольшой
                    б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?
                    Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?

                      0
                      Тогда от PostgreSQL вы вообще бежите как черт от ладана?

                      да. убер хорошо расписал как все хреново там где нет полноценного undo. собственно enterprisedb — основной вкладчик в постгрес, признает преимущество undo и уже года 3 пилит undo для постгрес

                      1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу

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

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

                      пару лет назад Таблойд с sql.ru гонял тесты с 256 параллельными тредами. ФБ просто вставал колом. он отрепортил с десяток чудовищных проблем и наглядно показал, что такие нагрузки никто на ФБ не практикует

                      Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?

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

                      0
                      О, Йо на хабре. Я думал, человек уже перерос флеймы и изжил свои детские комплексы по отношению к ФБ, ан нет, флаг «сравнений субд» снова поднят, и снова та же чушь, что на sql.ru десятком лет раньше.
                  +1

                  Это конечно интересно… но что может побудить в 2019 выбрать именно эту бд для нового проекта? Чем она лучше более популярных? Я бы с удовольствием прочитал аргументы, а лучше статью) о том зачем вообще выбирать firebird.

                    +2
                    Да, лучше статью написать, раз есть интерес :)
                      +1
                      А можно ещё статью с нюансами про кластеризацию/репликацию?
                        0
                        Поддержку. Интересна статья с рассмотрением вопроса о репликации.
                    +2

                    Интересная статья, но страдает от распространенного явления — во многих местах говорится, что надо сделать, но не объясняется, почему и зачем.


                    Число VMA по умолчанию 64K, его необходимо увеличить в 4 раза

                    Зачем? На что это повлияет применительно к работе этой системы? А если в 2, а не в 4? А если в 8? А если БД не 600 гиг, а 100 или 1200?


                    Увеличили минимальный зарезервированный размер памяти для специальных процессов ОС

                    Опять же — а в каких случаях надо увеличивать? А если не увеличивать? А если еще больше увеличить? А от чего зависит, насколько увеличивать (косвенно указан только объем ОЗУ сервера безотносительно сценариев использования — неужели больше ничего не влияет?)


                    DefaultDbCachePages

                    Достаточно странный мотив для ограничения — а вдруг у нас там тестовая база… А если у нас все-таки нормальная контролируемая среда и база только боевая — тогда как?


                    FileSystemCacheThreshold

                    Тут вообще надо начинать с вопроса "а зачем нам этот файловый кэш на сервере БД нужен и нужен ли вообще, ибо если мы кэшируем сначала в ОС, а затем в кэше самой БД — зачем нам этот оверхед". И не упомянуто, что ежели всё-таки почему-то нужен, размер этого кэша тоже неплохо бы контролировать (при этом забавно, что в, судя по всему, вашей же презентации двухлетней давности про схожую БД тема раскрыта несколько более полно).


                    TempCacheLimit

                    Индивидуально для каждой системы — ОК, а как определить-то? Ну вот у кого-то другая структура БД, другие паттерны нагрузок и размеры, и что ему толку от ваших "20ГБ"?


                    LockMemSize и LockHashSlots

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

                      0
                      Запрошенные комментарии тянут на пару глав в книге :) Статья и так довольно объемная получилась — и, как Вы сами правильно заметили, мы вопрос тюнинга на семинарах и конференциях Firebird постоянно освещаем. Коротко — VMA надо увеличить из фрагментации памяти, число потребляемых VMA легко мониторится, до 2000 юзеров 250К достаточно (не надо рассказывать как VMA мониторить? :) Ограничить дефолтный DefaultDBCachePages — это полезная соломка из нашей практики. Файловый кэш всякой линуксовой СУБД нужен — если это не MSSQL, конечно :) TempCacheLimit — определить очень легко, используя HQbird с параметром TempSpaceLogThreshold (TempCacheThreshold). По лок таблице теория на отдельную статью тянет, причем довольно бесполезную статью, т.к. рекомендация точно такая же будет.
                      0
                      Для БД настроена репликация на резервный сервер (вопрос о репликации вне рамок этой статьи).

                      Было бы интересно почитать как это делается для Firebird
                        0
                        Я б не стал хвалить то что создал редсфот, их проклинают каждый день все работники фссп за это тормознутое убожество с которым им приходится каждый день работать… Каждый день задумываюсь почему не выбрать для столь нагруженных сервисов что-то более производительное…
                          0
                          То есть база на 3ТБ таки тормозит? Информация 146%?
                            0
                            База на 3Тб это от системы межведомственного взаимодействия, она на госуслугах работает и ее производительность строго мониторится. Нет, она не тормозит. А человек в комментарии, как я понимаю, говорит о локальной БД приставов, на которой, как я понял из личной переписки, запускаются произвольные запросы и кастомные отчеты.
                          0
                          1) Предложил однажды заказчику переехать с windows сервера на Linux на сервере под инфоклинику, на что получил гениальный по своей сути отказ. Нет, нельзя, сдс-овцы не умеют пользоваться линукЦом. Мой вопрос, что они должны делать на сервере, кроме одной команды systemctl restart firebird, ответа не получил. Остаёмся на винде.
                          2) После переезда на 3 версию фаерберда в режим superserver, появилась странная особенность: если одновременно от сервера отваливается примерно 15-20 клиентов, например из-за обрыва связи, то firebird иногда почему-то перестаёт принимать новые подключения. Штатно как сервис перезапуститься не может, приходится убивать сам процесс.
                          3) сама инфоклиника, на мой взгляд какой-то чемодан без ручки.
                          — Ребят, а вы можете собрать sql-запрос, чтобы сосчитать количество оказанных услуг?
                          — Нет не можем, если услуги по профосмотрам, то они в одной таблице, а если платные, то в другой.
                          — Это как так?
                          — ну вот так…
                          — А вы можете посчитать себестоимость услуги по расходным материалам?
                          — ну если каждая услуга будет в отдельном приеме, то да. А если несколько услуг в одном, то будет непонятно, что к чему относится. И такая же фигня с оплатой, нельзя в одном приеме оплатить одну услугу полностью, а вторую полностью оставить в долг, только разделять на два приема…
                          — Ребят, а вы можете в таблицу добавить новый столбец, и вносить туда данные?
                          — нет, не можем.
                          — как так-то?
                          — ну там или столбец пропадёт после обновления, и в интерфейсе программы он все равно не появится.
                          — а если заказчику захочется учитывать какой-то новый параметр пациента или врача для лечения, ну например, совместимость врача и пациента по знаку зодиака, (реальный случай, кстати) то что делать?
                          — ну это будет скорее всего платная доработка со стороны СДС.
                          — шта?
                          — ну да, так и живем…
                          И тут выходит статья на хабре про инсталляцию инфоклиники на 1,5к пользователей. Даже и не знаю, как реагировать, пожалеть людей или порадоваться за них.
                            0
                            Добрый день. Не знаю, что у Вас за заказчики, но 90% больших инсталляций Инфоклиники на Linux. Что касается вопросов с SuperServer 3 — добро пожаловать к нам в техподдержку, тут разбираться надо, а телепатический локатор плохо работает. По п3 — это лучше к самим СДСовсцам, но я соглашусь с ними, что лезть в схему, которая будет обновляться в рамках техподдержки приложения вендором, нелогично. Это же не инхаус разработка, вы даже правами на структуру БД не владеете.
                              0
                              Но я соглашусь с ними, что лезть в схему, которая будет обновляться в рамках техподдержки приложения вендором, нелогично.

                              В таком случае, уровень этой разработки, как вы говорите «инхаус», а не для крупной ЛПУ, которой нужна уже полноценная ERP-система, в которой нужно добавлять произвольные справочники и классификаторы, в том числе цветов глаз и знаков зодиака, как бы это парадоксально не звучало.
                                0
                                Насколько я понимаю, там можно добавить произвольный справочник, и вообще все что угодно, просто за это хотят денег :) Т.е. Вы хотите на бизнес-модель СДС пожаловаться? Ну это точно не со мной надо обсуждать
                                  0
                                  Нет, я хочу пожаловаться на инфоклинику, не знаю только где :)
                                  Я долго сопровождал одну широко известную в узких кругах синюю программу, и думал что все плохо. Но снизу постучали.

                          Only users with full accounts can post comments. Log in, please.