Vad72Но я заметил, что там, где стоит MS SQL, оно работает без проблем и админят простые студенты за 1500 грн. На DB2 и ORACL-е уже не так всё просто. Там держат дорогих специалистов и в количестве чуть ли не на порядок больше. Кроме того, устанавливается всё как-то очень долго, работает медленно. Но у Оракловцев есть аргумент – платформонезависимость.И что же там делают "много дорогих специалитов" на DB2?
В ней, родимой, все максимально автоматизировано. Если не нужны изыски (т.е. типовая тиражируемая система) - поставил, настроил, забыл - все само работает, все настройки по-умолчанию в "авто". Установка в несколько кликов, и те можно сохранить в файлике и аналогичные ставить в темную.
Платформонезависимость - в ассортименте. Для АСКУЭ, например, (не о ней речь?) за глаза хватит бесплатной Express-C, проверено. Express и Workgroup, если будут нужны, стоят недорого.
1. Администрирование автоматическое, все настройки - бесплатными тулзами с визардами, есть оповещения на мыло и т.д.
2. Если тиражируемая система - достаточно удаленного сопровождения разработчиком, я на некоторых серверах годами почти ничего не делаю. Сами живут. Тем более, что в Украине ("грн."), насколько я знаю, по DB2 спецы есть.
3. Драйверы - любые. Есть add-on к VS. Репорт генераторы к СУБД отношения не имеют, можно воткнуть любой из большой кучи вариантов - зависит от среды разработки. Или у Вас юзеры сами с нуля в отдельной системе отчеты разрабатывают? :)
4. Требования к железу минимальны.

Минус - "версионность" только в виде currently (last) commited, но для биллинга этого вполне достаточно.
Vad72"На DB2 и ORACL-е ... устанавливается всё как-то очень долго, работает медленно"Моей фантазии не хватает представить что именно надо сделать с DB2 9.7, чтобы она долго устанавливалась и медленно работала. Только если очень постараться. "Тут помощник нужен" (с)

Yo.!, распределенный биллинг весьма специфичная задача.
Все зависит от объема и состава "сырых" данных.
В общем случае при распределенной системе лучше и проще "сырье" обрабатывать на местных простеньких серверах, а "наверх" отправлять агрегированные данные, а не забивать каналы кучей исходного мусора.
Да и каналы в регионы, скажем мягко, и в России не всегда можно надежные получить. Тем более если вдруг нужен on-line биллинг.

Yo.!вы там HD видео с показателями счетчика бабки из 4й квартиры собрались гонять ? вы планируете предлагать он-лайн билинг деревне гадюкино, что бы обеспечить дополнительные преимущества централизованного отопления ? Подкупает Ваша трогательная готовность строить умозаключения по никак не описанной задаче.
Биллинг энергосети, мягко говоря, немного отличается от биллинга бытовых потребителей.
Даже не говоря о сложной топологии, куче поставщиков-потребителей, "перетоках" и т.д.
Навскидку из простого - в on-line очень неплохо было бы отслеживать, например, пики превышения разрешенной мощности хотя бы по пром. потребителям. Эти пики могут привести к преждевременной кончине недешевых трансформаторов на подстанциях со всеми вытекающими. А это уже серьезная головная боль для сетевой компании и серьезные бабки для сбытовой.

Vad72В базе биллинга на МС СКЛ используются хранимые процедуры, которые выполняют часть "математики" средствами СУБД. В биллинге на ДБ2 и ОРАКЛЕ используются только таблицы (было так задумано, чтобы не привязываться к конкретной СУБД).Вот и ответ по "низкой" производительности 2-х последних. Раз это разные биллинги, проблему надо искать в том из них, который тормозит, а совсем не в СУБД.

Yo.!бугога, вы на полном серьезе считаете, что за работой трансформаторов следит бухгалтерия ? Я на полном серьезе считаю, что за неработой сгоревших трансформаторов на подстанциях будет следить целый ряд органов различной компетенции. С понятными экономическими (и не только) последствиями. А даже кратковременное превышение мощности (и в результате перегрев) резко сокращает их (трансформаторов) и так сильно выработанный ресурс.
Кроме того, превышение установленной мощности должно быть (и таки является у буржуев) существенной частью тарифных "штрафов" для потребителей.