Станислав Макаров

ORM-ку сверху накиньте, вместо прямого ADO.Net, и будет вам современные технологии. В тренде, очевидно, Entity Framework, хотя NHibernate - нестареющая классика.
Можете заморочиться над архитектурой, вплоть до разделения на клиент и сервер - тогда будет место и для Web API.
Или другой вариант - подтащить документую БД, хотя для бухгалтерии не факт что это хорошее решение (разве что в пару к реляционной, для хранения характеристик ваших товаров).

Сложно вам посоветовать в такой ситуации что-либо. Интересно, чем занималась контора та, что программисты C# с sql не знакомы, разве что играми..
В целом вам надо ознакомиться с современным представлением о реляционных БД (вы же все-таки аналитик, вам нужно знать на разных уровнях и масштабах), с архитектурой приложений, использующих РБД (толстые и тонкие клиенты, веб-приложения), и потом уже некоторые детали касающиеся языка.
С точки зрения программиста C#, я бы от вас как от аналитика ожидал знание различных принципов и дисциплин доступа к рел. данным, а именно:
- использование ORM: когда можно и нужно), когда хочется, но нельзя, когда можно "толстую" ORM (Entity Framework, NHibernate), а когда - тонкую (LINQ to SQL); использование кода на стороне БД - триггеры, хранимые процедуры;
- принципы построения слоев доступа к данным в сочетании с бизнес логикой (паттерны и антипаттерны в этих ситуациях, например Anemic Data Model);
- способы контроля версий схемы реляционной БД - миграции, source control для триггеров и хранимых процедур (если они есть), политики обновления схемы вместе с выкатыванием новой версии ПО;
- формирование тестовых данных в тестовых базах;

Вот если сможете по этим вопросам проконсультировать, то разработчикам останется только подучить SQL и конкретную ORM, если будете использовать.

> где наряду с NoSQL еще и графы используются
интересная формулировка)

> В каких случаях это в БД может быть полезно?
во всех задачах, где глубина и "разнообразие" связей между сущностями сравнимо с количеством этих сущностей.
Возьмем для примера две простые ситуации:
1) есть заказ в интернет-магазине с некоторым числом заказанных товаров. Вне зависимости от того, реляционную модель вы будете использовать или какую-то еще, скорее всего вам будет удобно рассматривать две сущности: Order и OrderItem. В первую вы добавите сведения обо всем заказе целиком (инф. о клиенте, дату заказа, выбранный способ доставки, способ оплаты и т.д.). Во второй сущности у вас будет, например, id товара и его количество (1 микроволновка, 2 флешки, 5 CD-R). Теперь, чтобы вы могли знать, что какие-то OrderItem имеют отношение к конкретному Order, вам следует тем или иным способом смоделировать связь. Если у вас SQL-база, вы добавите к Order-у поле Id, а к OrderItem поле OrderId и сделаете внешний ключ. Если у вас документная база, то, к примеру, можно весь заказ с его элементами разместить в одном json-документе, и элементы заказа будут подобъектами в массиве items объекта заказа. Со временем у вас появится много заказов и много элементов заказов. Однако связи между ними у вас всегда будут достаточно простые: у каждого заказа будет некоторое количество элементов. Сами заказы вы связывать не будете, как не будете связывать элементы заказа. Глубина связей сущностей будет ограничена одним переходом.
2) у вас есть социальная сеть (да, знаю, банальный пример), и конечно же у вас есть функция "добавить в друзья". В отличие от предудыщего примера, мы для рассмотрения можем взять только одну сущность - "пользователь", однако за счет того, что каждый каждого может зафрендить, у вас даже для одной сущности будет очень большой набор фактических связей, потенциально с большой глубиной (знакомые знакомых и т.д.).

Обе проблемы теоретически можно решить с помощью SQL баз данных, однако графовые базы будут выигрывать во второй задаче в сложных запросах по обработке связей (скажем, найти всех моих друзей, которые идут на такое-то мероприятие). Этот выигрыш вытекает из архитектурных особенностей графовой БД, например, в графовой базе часто при сохранении связи сохраняется "указатель" на физическое расположение связанных данных, в то время как в реляционной базе связи моделируются внешними ключами, и при обработке требуют выполнения операций поиска (пусть и индексированного). Вообще, в каком-то смысле связи в графовой БД это first-class citizens, а в реляционной БД связи моделируются программистом (ограничения целостности вроде внешних ключей просто помогают ему поддерживать данные в согласованном состоянии).

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

Если без холивара - то преимущество оно всегда одно - т.к. вы платите баб$сы, то имеете возможность позвонить в саппорт 24/7 и спросить, почему не стартует сервер СУБД после ваших манипуляций с ним. Конечно, для постгреса есть EnterpriseDB, и это довольно серьезные ребята, так что все упирается, как и всегда, в опыт и доверие. Оракл - это огромные вложения в инженерные решения, многолетний опыт поддержки по всему миру ну и прочие дела. Также, как и какой-нибудь DB2, которому тоже уже 40 лет стукнуло.
Когда вы храните в вашей БД данные стоимостью несколько миллионов долларов, становятся важны мелочи, не видные на первый взгляд - надежность восстановления после сбоев, отлаженность процедур бэкапа и восстановления, стоимость и оперативность масштабирования и еще 1000 и одна вещь.

Если коротко - то лучше сразу посмотрите на модель EAV, т.к. разбивать на отдельные таблицы имеет смысл только для ОЧЕНЬ специализированных магазинов, у которых весь бизнес вертится вокруг продажи конкретных товаров. Если у вас обычная розничная продажа, то лучше сразу от этого отказаться, т.к. все равно рано или поздно будут добавляться новые типы товаров и ваша БД будет усложняться до момента потери контроля над ее структурой.
Тут я предлагал решения для аналогичной проблемы: Как добавить товар в корзину?

Вам надо определиться с рядом требований к вашему приложению, в частности - на каком уровне абстракции оно работает с БД. Если на метауровне - т.е. для вашей программы нет ничего кроме набора неких таблиц и вьюх в базе (иными словами у вас чтото вроде стандартного шелла для работы с базой) - то это одна ситуация, и тут вам бы работать с INFORMATION_SCHEMA (чтобы без свитчей) и действительно собирать SQL-запросы самому. Если же у вас стандартные бизнес-задачи (создать запись о клиенте, заказе, ..., сохранить, отредактировать данные), и вы конкретно знаете, что у вас за таблицы и что там хранится, то почитайте про актуальные подходы к работе с данными в базах с использованием ORM, в случае дотнета - Entity Framework и NHibernate.