ALEXBORХотелось бы обсудить тему по поддержке в разрабатываемом приложении нескольких СУБД
Тема большая, я бы даже сказал, неподъемная. Практически слишком много различных вариантов по задачам, архитектурам и требованиям.

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

Во-первых, попытка остаться в рамках стандарта либо иным путем писать одинаковый или почти одинаковый код обречена на провал, многократно подробно обсуждалось, подходит только для Hello world.

Во-вторых, организация взамодействия "чего-нибудь" с сервером БД. "Что-нибудь" - это клиент или сервер приложений. Очевидно, что нужна та или иная абстрагирующая прослойка, отделяющая "детали взаимодействия с конкретным сервером" от всего остального. Я уверен, что с ростом требований стандартные решения, такие как JDBC, ADO или стандартные ORM-ы, перестанут удовлетворять в таком качестве. Практически сразу стоит закладываться на то, что эту прослойку либо писать самим, либо брать более-менее подходящую и вдумчиво дорабатывать.

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

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

В принципе возможен отказ от серверных процедур. Это не обязательно приведет к ужасам "все на клиенте", поскольку клиент вполне может отправлять на сервер скрипты, по сути те же процедуры, но не хранимые, а выполняемые на ходу. Однако, это все же заметно хуже хранимых процедур - дополнительные разборы, компиляции, проблемы с версионностью итп. Так что давайте о процедурах.

Единого языка создания ХП сейчас нет и в обозримом будущем не будет. На эту роль могут претендовать ява-сишарп, выполняемые на сервере, но это вряд ли выход в силу эффективности; им придется либо долго и мучительно делать то, что можно было бы сделать одной sql-командой, либо работать "вызывалкой SQL-ей", и тогда снова встанут вопросы универсального кода итп. Особого цимеса в этом пути я не вижу.

Таким образом, нам остается либо писать хранимки индивидуально под каждый сервер, либо снова воспользоваться прослойкой - научить ее генерировать ХП под нужный сервер. Именно это мне кажется наиболее перспективным направлением; мы описываем ХП точно так же, в метатерминах, на своем языке, генерим код под сервер и имеем возможность оптимизировать его, задавая тело ХП на нужном языке.

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

ALEXBORА можно привести здесь небольшой, но конкретный пример. Не совсем понятно как это делается, особенно вот это "мы описываем ХП точно так же, в метатерминах, на своем языке, генерим код под сервер и имеем возможность оптимизировать его, задавая тело ХП на нужном языке".
Хм, боюсь небольшого примера не выйдет, все будет достаточно громоздко. Собственно, все примерно так же, как с генерацией SQL. Прежде всего, "остальные уровни" должны знать, что существует процедура, например, ДвижениеТовара с параметрами (что,откуда,куда,сколько). Это дело абстрактной прослойки. Дальше, мы описываем эту процедуру в "наших" терминах. Для этого как правило придумывают собственный язык, получится что-нибудь типа такого:


Теперь, если запустим генерацию, для Oracle получим что-нибудь типа

Наконец, если сгенерированное тело нас по каким-то причинам не устраивает, мы должны иметь возможность указать: для этой процедуры должен быть вот такой оракловый код. И тогда инсталлятор просто применит готовое тело.

ALEXBORТо же самое, скорее всего, делают и ORM-ы, но повторяю, мы не знаем как...
Не проще ли воспользоваться готовым решением. Понятно, что .NET довольно молодая технология и качественных ORM, удовлетворяющих хотя бы минимальным критериям найти трудно. С другой стороны есть пример Hibernate под Java, на котором довольно успешно реализовано большое количество проектов...
"Проще" не всегда значит "лучше". Повторю изначальное утверждение: я совершенно уверен в том, что чем больше проект, тем меньше будут подходить стандартные решения; потребуется либо серьезно дорабатывать существующие и открытые, либо делать свое с нуля.

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