Вопросик про связку C# с базами данных

[Kvest]

Вопросик про связку C# с базами данных

Пишу программку, что-то типа личного органайзера. В ней предполагается сделать раздел "контакты", где будет храниться инфа о контактах, их телефонах, имейлах, и др. сведениях. Вопрос, где мне лучше хранить базу для контактов, во внейшней СУБД (например sql server) и связываться через ADO с ней или же можно не париться и использовать встроенный .net-овский dataset и экспортировать/импортировать базу в XML. Помню кто-то с данного форума мне когда-то подсказывал что мол ADO это большой выигрыш по быстродействию, но хочу отметить что у меня не клиент-серверное приложение, а просто программка для личного использования.

 

[ASokol]

Если данных не много, то посмотри на SQLite.

 

[Kvest]

Спасибо, посмотрю.

p.s: данных планируется не мало (хочу охватить широкий спектр ), кроме того я также хочу сделать возможность чтобы пользователь сам мог добавлять какие-то данные и инфу по ним.

 

[swisst]

я за XML

 

[Lam]

ИМХО SQLite - рулит в данном вопросе, довольно компактная, легко настраивать и работать + получаете все прелести SQL запросов.

 

[neocortex]

А чем SQL Server Express или даже SQL Server Compact Edition (ИМХО именно для таких целей и затачивался) не подходит? Все ж таки родное MS'овское решение...

Насколько я помню, Compact Edition даже устанавливать не надо - он идет как набор DLLек, которые можно распространять со своей прогой.

 

[nigma]

я за XML + LINQ to XML

 

[neocortex]

я за XML + LINQ to XML

Затраты на сериализацию/парсинг в XML, плюс затраты на переписывание всего файла с данными при добавлении/изменении записей, а ради чего? XML хорош как формат обмена данными, в первую очередь - между различными платформами. А как средство постоянного хранения - ИМХО лучше использовать что-то заточенное именно для этих целей.

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

 

[Kvest]

я за XML + LINQ to XML

Забыл добавить что уже начал писать под 2й фреймверк где linq нету

В общем исходя из всего что посоветовали думаю выбирать стоит между sql server и sqlite. Попробую разобарться сначала с sqllite, вроде он полегче намного будет. Спасибо всем отписавшимся.

 

[nigma]

Затраты на сериализацию/парсинг в XML, плюс затраты на переписывание всего файла с данными при добавлении/изменении записей, а ради чего? XML хорош как формат обмена данными, в первую очередь - между различными платформами. А как средство постоянного хранения - ИМХО лучше использовать что-то заточенное именно для этих целей.

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

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

Так же все зависит в какие сроки это нужно сделать, даже если делать с использованием SQLLite или SQLServer, с использованием того же LINQ to SQL намного быстрее будет написана апликуха. И опятже если так хочеться использовать сторед процедуры LINQ to SQL замечательно позволяет их использовать.

 

[Klez]

p.s: данных планируется не мало (хочу охватить широкий спектр )

котнтакты в записной книжке больше 2 гигабайт?

 

[Kvest]

котнтакты в записной книжке больше 2 гигабайт?

ну да, для всего Китая

 

[A1feG]

Забыл добавить что уже начал писать под 2й фреймверк где linq нету

В общем исходя из всего что посоветовали думаю выбирать стоит между sql server и sqlite. Попробую разобарться сначала с sqllite, вроде он полегче намного будет. Спасибо всем отписавшимся.

Никто не мешает перейти на 3.5 Фреймворки обратно совместимы.

А по теме уж лучше использовать АДО, чем датасеты. Впрочем можно поглядеть в сторону

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.