Re[2]: C# и Базы данных - .NET

Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.

Здравствуйте, STEEL, Вы писали:

STE>Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.

Так же множеством отличных провайдеров для разных БД.

тут для для IB/FB:
http://www.firebirdsql.org/index.php?op=files&id=netprovider

Еще можно более-менее универсально через ODBC&OleDB, но "родной" .net-провайдер обычно лучше.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, STEEL, Вы писали:

STE>>Я только начинаю осваивать ДОТНЕТ, да и вообще Студию .НЕТ, ранее работал с Дельфи. У меня такой вопрос закрался, как вообще работать с базами, помимо MS SQL Server ? Например с Interbase/FireBird ? Для Дельфи существует масса отличных компонентов для различных бд.

F>Так же множеством отличных провайдеров для разных БД.

F>тут для для IB/FB:
F>http://www.firebirdsql.org/index.php?op=files&id=netprovider

F>Еще можно более-менее универсально через ODBC&OleDB, но "родной" .net-провайдер обычно лучше.

А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?

AM>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?

Убирается лишний посредник и имеется больше информации о том, с какой базой работаем, ее детали, что потенциально дает следующие бонусы:

1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно.
2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов.
3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, fmiracle, Вы писали:

AM>>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?

F>Убирается лишний посредник и имеется больше информации о том, с какой базой работаем, ее детали, что потенциально дает следующие бонусы:

F>1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно.

В некотором роде да:

OleDbConnectionStringBuilder cb = new OleDbConnectionStringBuilder(connection_string1);
Console.WriteLine("Provider: " + cb.Provider);
Console.WriteLine("Data Source: " + cb.DataSource);

F>2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов.

Все зависит от прямоты рук разработчика провайдера. Если сравнивать с System.Data.OleDb то там что-то совсем все плохо. Это лишь неудачная попытка использовать OleDb в контексте .Net.

F>3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.

Набор стандартных ошибок OleDb ~ 200. Набор контролируемым ошибок БД приложением определенно невелик. Гораздо эффективнее не контролировать, а исключать возможность их появления на уровне логики. Я обычно ограничиваюсь проверкой — была ошибка или нет с выводом её описания. Хотя если такие ошибки появляются — значит есть проблемы в реализации приожения Иерархия исключений — наверное плюс.

F>В общем и целом родной .net провайдер для конекретной базы может быть эффективнее в работе и при этом удобнее чем OleDb, хотя, конечно же, всегда можно написать провайдер неудобным и неэффективным

Насчет производительности Native Provider-a не могу судить. Хотя если оценить общую тенденцию производительности .Net based приложений не думаю, что он будет эффективнее работать с DB API чем его com-аналог.

Небольшое резюме:
1. Существующая реализация System.Data.OleDb имеет недоработки и весьма неэффективную реализацию. Есть подозрения, что все это следствия помыток обеспечить совместимость с наибольшим количеством типов баз данных, хотя наверное Правильно было бы реализовать весь потенциал OleDb интерфейсов, а их реализацию с другой стороны оставить на откуп разработчикам OleDb Provider-ов
2. Native провайдер безусловно при грамотной реализации способен обеспечить большую функциональность, специфичную для конкретной базы данных, но вместе с тем лишает разработчика использовать свои приложения с различными БД.

Здравствуйте, fmiracle, Вы писали:

AM>>А можно поинтересоваться чем лучше .Net провайдер от связки OleDb Provider — ADO.Net ?

F>Убирается лишний посредник

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

F>1. Расширения, специфичные для данной базы (типа ConnectionBuilder и т.д.) — не критично, но иногда весьма удобно.
F>2. Более эффективные обращения к базе — например, для управления соединениями, запроса прекомпиляции команд или извлечения результатов.
F>3. Опять же, поскольку четко известно что за база, может предоставляться более подробная информация об ошибках — либо иерархией исключений, либо полями в единственном классе исключения.

Ты не поверишь, все это есть в рамках OLEDB интерфейсов. Расширения тоже можно сваять, но вот вопрос — зачем?

Здравствуйте, fmiracle, Вы писали:

F>Так же множеством отличных провайдеров для разных БД.

F>тут для для IB/FB:
F>http://www.firebirdsql.org/index.php?op=files&id=netprovider

а при установке приложений, написанных с использованием этого провайдера, на
"голую" машину его нужно устанавливать?

F>>тут для для IB/FB:
F>>http://www.firebirdsql.org/index.php?op=files&id=netprovider

SVL>а при установке приложений, написанных с использованием этого провайдера, на
SVL>"голую" машину его нужно устанавливать?

Вроде нет..
Я почти не пользовался Firebird за исключением пробы применить его как embedded (но только пробы — окончательно я выбрал SQLite) — в виде embedded работало без дополнительных установок, насколько я помню.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>