MaxFX9 апр 2009 в 06:16

Использование SQLite в .NET приложениях

7 мин

166K

.NET * SQLite *

+43

Комментарии 48

logman 9 апр 2009 в 06:29

Хороший обзор. Сам я очень давно не использовал sqlite, еще с момента, когда там были разные прослойки импортирующие методы их не Net сборки. Очень хорошо, что ее закукожили таки в DbProviderFactories.

sse 9 апр 2009 в 06:54

Хорошая статья. А каковы преимущества использования под .net SQLite, а не SqlCe?

MaxFX 9 апр 2009 в 07:29

Использование SQLite или SqlCe — вопрос личных предпочтений. Мне в SQLite нравится, что для работы достаточно одного или иногда двух файлов библиотек, чтобы все функционировало. Получается очень компактно.

outcoldman 9 апр 2009 в 08:14

в SqlCE нету вроде поддержки хранимых процедур, а в SQLLite есть?

MaxFX 9 апр 2009 в 08:55

Не исследовал эту тему. Но насколько мне известно — SQLite не поддерживает хранимых процедур (в документации по этой теме ничего нет).

outcoldman 9 апр 2009 в 09:14

тогда действительно выбор основывается на личных предпочтениях…

dmzkrsk 9 апр 2009 в 10:57

Помню писал как-то на C++ и SQLite
Можно было определять свои функции на си и использовать потом в SQL запросах

lrrr 9 апр 2009 в 21:50

Нее, Sqlite *намного* дальше от «взрослой» RDBMS по сравнению с SqlCE. Другое дело что далеко не всем нужны эти фичи, а sqlite если что можно доточить, исходников там не так уж много.

Li0liQ 10 апр 2009 в 08:41

Нет, в SQLite их тоже нет. Зато есть триггеры ^_^

dimitrymd 6 июл 2012 в 06:47

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

iv_s 9 апр 2009 в 07:02

Года три назад писал небольшое десктопное приложение. Тоже нужна была embed база данных. Тогда мой выбор пал на Firebird, там тоже есть embed версия. Сейчас же часто использую SQLite. Кстати, и у MySQL есть embed версия, но ее я не смотрел.

merkator 9 апр 2009 в 08:09

Я тоже пару лет назад несколько приложений небольших делал с embed Firebird, вполне неплохо работало. А вот почему сейчас все же SQLite? Чем-то удобнее оказалось? Спасибо.

iv_s 10 апр 2009 в 04:15

Просто я уже давно не под .net пишу, а на Ruby. Во первых там SQLite более популярная, и с лучшей поддержкой. У Firebird возможности конечно по-богаче, но для маленьких приложений они обычно не нужны, а остальные различия стираются слоем ORM.

merkator 10 апр 2009 в 04:38

Понятно. То есть создание на Ruby приложений с БД нисколько не сложней, чем в .NET?

iv_s 10 апр 2009 в 05:00

Лично мне кажется, что даже легче. Есть три основные библиотеки для ORM: Sequel, DataMaper и ActiveRecord из Rails. Все они предоставляют объектный маппинг к базе, т.е. непосредственно про SQL можно забыть. Простой пример на Sequel:

#подключились к базе
DB = Sequel.connect('sqlite://test.db') #подключаться можно к любой СУБД, для которой есть адаптер
#создали таблицу
  DB.create_table :limits do
    primary_key :id
    String :ip
    int :clicks, :default => 0
    
    index :ip
  end

#объявили класс с маппингом
#для каждого поля в таблице будет сгенерирован геттер и сеттер
#также в него можно добавить любые свои методы для работы с моделью
#можно создавать отношения типа has-one has-many и many-to-many
#и валидаторы для полей
class Limit < Sequel::Model
end

l = Limit.new
l.ip = "127.0.0.1"
l.save #добавили в базу новую запись
l = Limit.find(:ip => "127.0.0.1") #получили запись из базы

Эти библиотеки можно сравнить c NHibernate, но в силу динамичности языка, и использования соглашений вместо конфигурации, использовать их проще и удобнее.

merkator 10 апр 2009 в 05:06

Потрясающе :)
Я все хотел добраться до Ruby поосваивать, но все руки не доходили. Спасибо за пример!

iv_s 10 апр 2009 в 05:15

Всегда пожалуйста:)
Только один совет, лучше начать изучать Ruby с самого Ruby, а не Rails, как обычно делают.

merkator 10 апр 2009 в 05:25

Рельсы меня как раз и не интересуют, а вот приложения было бы интересно…

Mephistophele 9 апр 2009 в 07:11

LINQ не поддерживается?

Mephistophele 9 апр 2009 в 07:15

Простите, не увидел сразу, что поддерживается :)

PingWin 9 апр 2009 в 07:20

Данный провайдер так же позволяет задействовать все дополнительные возможности последних версий .NET, такие как LINQ, Entity Framework.

wolf13h 9 апр 2009 в 08:28

Есть очень хороший пример работы с этой базой в asp.net mvc называется SharpArchitekture. В основном там она используется для написания тестов.

sse 9 апр 2009 в 11:23

Пример-то хороший, только сама SharpArcitecture — совершенно гадская вещь. Чего стоит их отказ от Spring.net и куча багов и compatibility issue. К сожалению, проект рожден мертвым.

wolf13h 9 апр 2009 в 12:13

Ну отказ от spring.net вполне правильная вещь. Мне не нравиться xml а fluent spring ну уж очень сырой. И кстати ничего не мешает вернуть его назад. Там практически везде используется CommonServiceLocator так что этот продукт IoC агностичен. Я тоже не особо рад что они выбрали Castl-овский, но мне поменять контейнер на StructureMap заняло час. Куча багов? Хм написал уже проект на нем и что то не нашел. Что Вы имеете в виду под Compatibility issue? Проект очень хороший(для меня по крайней мере) и быстро развивается. В общем каждому свое.

sse 9 апр 2009 в 17:10

Не совсем с Вами согласен.

Во-первых, Spring.net — это не только IoC-контейнер. Использовать его исключительно в этих целях нет смысла, проще взять NInject. Windsor не сильно отличается от Spring.net по части конфигурации — и там, и там это можно сделать через API, единственное, что у Windsor есть еще Binsor — DSL поверх Boo.

Быстро развивается и нет багов — видимо, я давно его смотрел (еще когда он был на СodePlex, и одного взгляда на исходники хватило, чтобы больше в его сторону и не глядеть)

Насчет container-agnostic — это Вы правильно говорите, поддерживаю.

Насчет compatibility issue — имею в виду, что попытка прикрутить к нему что-нибудь превратится в головную боль. Хотя может, я просто что-то недопонял в нем. Как в нем рулить транзакциями, например?

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

wolf13h 9 апр 2009 в 18:43

Ну спринг это скорее вопрос личного предпочтения.
Как расширить? Да так же как и сам asp.net mvc. Шарп арх это не более чем набор библиотек просто собранных в единый проджект темплейт. Поэтому добавление функциональности достаточно просто. Транзакции. Во первых можно использовать стандартные нхибернейтовские или можно использовать фильтр акшена который весь экшн оборачивает в транзакцию. Насчет т4 согласен это не очень хорошо сделали.

sse 9 апр 2009 в 18:52

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

Насчет транзакций — имхо очень нехорошо использовать родные транзакции NHibernate, потому что завязывать остальной код на них, в том числе и тот, который я собираюсь прикрутить извне — это неправильно. Этим мне и понравится Spring.net, что там есть абстракции для этих дел и многих других.

Спасибо за комментарии.

len 9 апр 2009 в 08:54

Спасибо за статью! Как раз сегодня полночи пыталась ЭсКюЛайт в приложение на ДотНет внедрить :)
Чувствую, сегодня ночью внедрю-таки.

leotsarev 9 апр 2009 в 09:26

Собственно, не очень четко раскрыто, как предлагается использовать SQLite.
Собственный мануалы SQLite рекомендуют использовать ее вместо кастомных форматов файлов — в режиме открыл файл BEGIN TRANSACTION, по сохранению сделал COMMIT.
Т.е. исключительно локально

MaxFX 9 апр 2009 в 09:50

>Собственно, не очень четко раскрыто, как предлагается использовать SQLite.
Я для себя писал телефонный справочник с использованием SQLite например. Известные примеры использования SQLite есть на википедии, наверное, они лучше всего очерчивают область применения данной СУБД.

>Собственный мануалы SQLite рекомендуют использовать ее вместо кастомных форматов файлов…
Тоже хороший вариант использования. Но я думаю, что SQLite проектировали не только для использования в качестве локального источника данных, личная практика показывает — что SQLite можно без проблем использовать для небольших веб-приложений.

chanaev 9 апр 2009 в 11:05

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

MaxFX 9 апр 2009 в 11:17

Пока мне хватает возможностей Server Explorer из Visual Studio. По крайней мере таблицы, индексы, ключи, констреинты и триггера настраиваются без проблем. Правда я и не использовал SQLite для каких-либо особо сложных баз данных.

chanaev 9 апр 2009 в 12:23

Триггеры нельзя с помощью SQLite Designer создавать/редактировать. Только просмотр.
Вообще этот аддон к студии предоставляет довольно скромные возможности.

MaxFX 9 апр 2009 в 13:02

Если SQLite Designer'а не хватает, то можно воспользоваться этим инструментом SQLite Administrator.

>Триггеры нельзя с помощью SQLite Designer создавать/редактировать.
Подтверждаю. Сам создавал trigger'ы программным способом. Наверное исправят в следующем релизе.

chanaev 9 апр 2009 в 13:15

SQLite Administrator программка неплохая, но криво работает с UTF-8/Unicode. И есть немного претензий к интерфейсу, поэтому я сейчас использую аддон к ФФ — SQLite Manager.

MaxFX 9 апр 2009 в 13:50

Спасибо за упоминание SQLite Manager к FF. Сегодня посмотрю.

self 12 апр 2009 в 18:33

А зачем связи во встраиваемой базе данных для дотнета? Связи нужно делать в DataSet-е. Дополнительные связи в БД только все усложнят и не дадут ничего полезного.

zabr 9 апр 2009 в 11:39

У меня возникла вот такая проблемка — sqlite.phxsoftware.com/forums/t/1632.aspx.
Никто не знает как вылечить?

midday 9 апр 2009 в 11:45

Наверно надо точку в конце ссылки убрать ;)

elw00d 9 апр 2009 в 11:48

Кстати, SQLite можно прикрутить к мапперу IBatis, и можно использовать интерфейс IBatis, практически не оглядываясь на особенности SQLite.

atomicxp 9 апр 2009 в 14:44

Ещё есть Mono.Data.Sqlite, для 1.1 и 2.0.

stoune 9 апр 2009 в 21:43

Меня от использования SQLite.NET остановила неразвитость инструментов (год назад) и отсутствие комерческого вендора который мог бы осуществить комерческую поддержку. Потому выбрал MS SQL Compact. Прямо сравнить сложно, но мне и не очень нужно, нужный мне функционал реализован, больших сложностей не нашёл, с выходом 3.5 SP1 появился EF да и сам движок стал более совершенен, потому от «добра добра не ищут»

RendeRR 13 апр 2009 в 23:06

— добавил ссылки на System.Data.SQLite и System.Data.SQLite.Linq
— добавил в проект Linq to SQL Classes, открыл в дизайнере
— перетаскиваю SQLite таблицу из Server Explorer
— ошибка:

— Microsoft Visual Studio
— The selected object(s) use an unsupported data provider.
— OK Help
— VS 2008. Что делаю не так? Спасибо.

RendeRR 13 апр 2009 в 23:15

отвечаю сам себе :)
судя по этому посту (такая же ошибка): sqlite.phxsoftware.com/forums/p/1408/6105.aspx
linq2sql не поддерживается :(

d9k 18 апр 2009 в 16:59

Как её присоединять с Visual Studio C#- то?
Всё перепробовал- не получилось. Опишите по шагам, пожалуйста. А то не находит System.Data.

MaxFX 20 апр 2009 в 07:30

Устанавливаете Designer add-in к Visaul Studio и добавляете ссылку на Syste.Data.SQLite.dll (через Add Refrence).

d9k 20 апр 2009 в 13:17

Спасибо!) а можно только вэб-приложения делать? Обычные нельзя?

К си++ не прикрутится?
А то я что только не делал- и сам компилировал dll-библиотеку и разные версии скачивал- компилятор пишет, что не может прочитать dll, либо пару десятков «unresolved external symbol ...» выдаёт.

MaxFX 20 апр 2009 в 13:39

Для C++ лучше использовать sqlite3.dll. System.Data.SQLite.dll предназначена для управляемого кода.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий