VSVLADRoken,

Гугли:

Из всего списка, только последнее имеет смысл. Все остальное - верный способ получить полное непонимание что такое SQLite.


Roken, www.sqlite.org - твой самый верный и правильный источник всех знаний по SQLite.
Оттуда же и скачиваешь все что нужно для работы под Windows.

YUBAVSVLAD, Достаточно давно администрировал систему записи телефонных переговоров на основе MS SQL Server.У тебя есть большая СУБД? Работает? Ну и чего не хватает? Приключений?

YUBAВ SQLite - Так как пока в БД идёт запись, файл блокируется для остальных потоков. Т.е. SQLite - небыстрая БД с плохоразвитой системой управления.Одно с другим не связано. SQLite это ВСТРАИВАЕМАЯ база данных. К ней не надо подходить с серверными привычками.

YUBAВ общем, единственное достоинство - компактность и переносимость.Нет. Ее достоинство что она встраиваемая, а значит расширяемая и персонализируемая. Конечно если тебе Очень Надо использовать OLE DB - то ты теряешь все вкусности. И тебе уже становится совершенно не важно какая там СУБД прячется за OLE DB.

YUBAТ.е. удел SQLite - небыстрые, несложные, работающие в одном потоке БД.Глупости.
YUBAТеперь ODBC -драйвер. Имхо ODBC технология пропала с горизонта где-то в середине 2000-х. SQLite нам предлагает OLE DB надстройку над ODBC. ИМХО, оч сложно.Глупости, глупости, глупости.
К тому-же SQLite тебе никаких надстроек не предлагает. Это тебе Микрософт предлагает. Читай учебники по OLE DB и ODBC. Можешь еще ADO взять для полноты картины.

YUBAПытаюсь понять в каких задачах ее можно применить.Во всех, где по каким-то причинам неудобно ставить сервер базы данных, но база данных нужна.
Одно приложение - один компьютер - одна база => SQLite идеален. Запихнуть в телефон приложение с собственной БД хранящейся целиком на телефоне => SQLite идеален. Сделать вспомогательную базу до которой никто другой кроме единолично хозяина не должен ходить (личная адресная книжка, личный кошелек, личная картотека) => SQLite идеален.

Но если у тебя сеть и к БД должны ходить несколько человек - SQLite не для тебя. Можно конечно и в этом случае извратиться с SQLite, но это уже придется самостоятельно решать множество задач синхронизации и намного проще будет взять любую из серверных СУБД. Те же MS SQL, Oracle, MySQL, Postgress...

YUBAЯ так понимаю, для регистрации данных от измериловки с несколькими потоками не оч подойдет.А это вообще задача не для СУБД.
Намного удобнее и надежнее писать с датчиков в несколько отдельных файлов, разрубая эти файлы на дневные/часовые сегменты. Потом брать готовые сегменты на другую машину и там их уже сливать в общую СУБД.
Писать с датчика непосредственно в СУБД можно только в том случае, если задержка записи вызванная блокированной таблицей (другим писателем, читателем или агрегатором) не повредит следующему измерению.
Вообще, если у тебя RT-задача - забудь про СУБД. Иначе наживешь себе сильную боль. А будет эта боль головной или анальной - будет зависеть от настроения твоего начальника.

YUBAWhite Owl,
Пока таких проблем не было, тем более все идет через буферные таблицы и потом по частям скидывается в базу.Благо в NET все предусмотрено.Ключевое слово "пока".
Как часто ты читаешь значения с датчиков? Раз в минуту? Раз в секунду? Раз в миллисекунду? Чаще? Реже? Можно ли задержать измерение на пару секунд? На минуту? На несколько минут? Сколько длиться само измерение? Сколько проходит времени от команды на контроллер датчика: "меряй!", до его ответа: "намерял столько-то"? Сколько тактов процессора ты тратишь на расшифровку ответа от измерителя? Можно ли пропустить одно измерение? Два? Сотню?

Если твои измерения идут раз в минуту с возможностью задержки на несколько секунд - тогда писать напрямую в СУБД наверное возможно. Меньше - уже скорее всего нельзя. А если мерять надо с точностью до миллисекунд - СУБД противопоказана совсем.
Ну а выбор .Net для измеряющей станции это - готовь вазелин бочками. И если у тебя пока проблем не было - ты очень удачлив и у тебя очень доброе начальство.

YUBAWhite Owl,
Ну, зачем же писать напрямую.) Есть обьект DataTable - в них и пишем. Аххххренеть! Бочкой вазелина вы не отделаетесь.
Не, в принципе идея хранить сырые данные в памяти это правильная идея. Накопили на страницу - сбросили пакетом. Опасно потерей данных на размер кеша, но и только. Но использовать для этого DataTable?! У вас же нет никакого контроля по объему данных. Никакого контроля над синтаксисом пакета. У вас же вообще никакого контроля над данными нет! Более дурацкого решения задачи представить сложно, разве что добавить на форму DataView и привязать этот DataTable к нему чтоб видно было чего там измерятель намерял. Ну а чё? Чем глупее решение задачи тем веселее, не так ли?
Теперь я верю что у вас есть "недостатки" в работе с SQL Server.
Да еще и мечты о нативном коде .Net...