Привет, селяне!

Есть оперативная табличка в SQLite на 15-20 строк, с 10-12 параметрами. Данные по строкам обновляются 1-3 раза в секунду. БД подключена к клиентскому ODBC.
Каким методом выгоднее (ресурсы/скорость/etc.) получать данные в 1С:
1. Через внешний источник данных?
2. Через ADO (COM) запросами?
3. Через ВК (забираем, строим логику в ВК, в 1С толкаем по необходимости)?

Не хотелось бы проходить путь, который кто-то, возможно, уже прошел...
Заранее спасибо!

Через http

И sqlite можно выкинуть. Чо без бд 20 строчек нельзя хранить никак что ли. Если совсем дикий, то через внешний источник.

(2) Входные условия видишь? База SQLite, подключена через пользовательский ODBC, или ты КИРПИЧ по жизни??? Есть то, что есть. Я тебя не просил оценку структуры давать, а как из этого проще выкрутиться...

а не булет ли блокирующего чтения?

(3) Не, я просто Кирпич, а вот ты по жизни. Нарисовал коня для телепатов и ждет адекватных ответов.

(5) А что я не так нарисовал? Обоснуй? Есть вводная, есть вопрос. Если ты не в теме освободи пространство... Нех лезти, с твоим чистым потоком сознания.

(4) Ну на чтении не блокируется, если ты имеешь ввиду ADO-ODBC, там и на записи нет блокировки.

(7) "на чтении не блокируется"
Расскажи это 1су с их эр в скулайте ))

Да пофиг блокировка. Читатель подождеь рару миллисекунд. Ничо страшного

(0) Данные в 1С нужны на клиенте или на сервере?

Если на клиенте то ВК с внешнее событие, если на сервере то веб-сервис в 1С поднимать и нечто внешнее пусть дергает.

(6) О, деревня с бодуна выползла, после вчерашнего. Селян своих ищет. Вчера, наверно, хорошо было.

(9) а писатель? Потом выясниться что программа не ожидает несанкционированного доступа и будет каждый раз при чтении из 1С крашиться

Если оба пишут, тогда плохо. Но пока не ясно из 1с туда будут писать или нет. Да и если будут тоже пофиг. Транзакция не долгая скорее всего.

Кто то же каждую секунду пишет в эту табличку

(8) (12) Тих, тих, это как так??? Если через ADO, то причем тут 1с?? Доступ то идет через драйвер SQLite3 ODBC driver. Что не так? Норумль работает и с блокировками, и с высокой нагрузкой. 1С только читает. Пишет прога на си от датчиков. Это данность, ее не сменить.

(11) Ну с тобой все понятно, чем дальще твой задрищенск, тем больше ты комплексуешь по этому поводу)))

(12) Подожди, как это крашиться??? А уровень изоляции и варианты блокировок кто-то отменил?

(15) в контексте вашего зоопарка и оборудование нельзя сказать какой вариант лучший. Более того при ваших небольших входных данных может оказаться что разница будет в районе стат.погрешности. Т.е. можно рассуждать о супер пупер способе, но у вас он невзлетит так как среда не подходящие (или версия SQLite). с другой стороны можно неделю потратит для написания оптимального способа что в конце прийти в мысли что тупо решая в лоб у нас будет сопоставимое время работы

(17) а ты уверен что драйвера датчика которые пишут туда это используют?

может они для скорения используют недокументированные фичи и в обход пишут напрямую

(20) Ну насколько я смотрель код на СИ, там все стандартно. Поднимают клиента ODBC и на  сервер(ODBC виндозовский) отправляют данные по протоколу. Драйвер лайтовский настраивается по блокировкам и изоляции уже в клиентском ODBC. Все просто. Мне хотелось бы узнать, что бы не переберать все варианты, каокй быстрее и дешевле по ресурсам. Из тех, что я написал в вопросе.

(16) Вот поэтому у меня проблем-то со связкой SQLite и 1С не возникает. Ты сходи там в свою сельскую библиотеку, туда книжек и брошюрок уже завезли. С примерами, с описаниеми... Читать-то, вроде, умеешь. Попробуешь, втянешся.

А выпытывать у тебя что значит "выгоднее" с твоей точки зрения никто не будет. Предложат тебе отдельный микросервис на GO, и колупайся. Вон, в (10) уже начали.

(0) юзай внешние источники данных

(21) ты правда думаю что выборка 10 строк это то на что строит тратить время в поисках выгоды?

Что лучше знаешь и гле быстрее напишешь то и выгоднее.
Какая выгода потрить день в написании ВК, отлаживать его, если по скорости работы он будет сопоставим с ВИД?

(24) А поговорить? (:

(26) Болтолог. Наверное ДЗЕН ведёшь? Гет лост бастэ. Твои детские комплексы и страхи в данном контексте не интересны...

(0) для начала обозначь приоритеты, что важнее

1. скорость записи или чтения
2. допустимо-ли потеря пакета при записи или черное чтение

потом определи сколько потоков читает и записывает

ну и на закуску дай примерное время на операцию записи и чтения

после всего этого можно будет и советовать

По факту выясниться что данные нужно читать не чаше чем раз в час. И будет и читать 20мс или 5 секунд - не критично. И чтать будет не человек, а робот который по этим данным будет строить свои данные и отправлять на почту раз в сутки отчет

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

(27) А порчу по фото накладываешь?

(30) как ты думаешь есть универсальный способ выборки любых данных и из любых источников с максимальной скоростью?
Где то кэширование позволяет ускорит получение результата в 10 раз, а где то затраты на кэширование превышают время выборки. и что тут советовать?

ну и еще - как я понял у тебя есть доступ к коду на с+ на котором написана приблуда которая пишет файл, на сколько я понял по количеству параметров никакая история данных в базе не хранится, от сюда очень простой вывод напрашивается, немного переписать прогу которая получает данные с датчиков и пишет данные в базу на COM сервер, и данные хранить исключительно в оперативке, а получать из 1с по COM (или DCOM+)

На мой взгляд этот вариант не сложнее чем написать свою ВК для получения данных из базы

(30)Была бы у меня гибкость в архитектуре, я бы на С склепал шустрый ODBC сервер непосредственно под это дело и подменил его для клиента. А дальше дергал бы 1С при изменении параметра. Но там все глубже, структуру менять нельзя. Это самый низ ТАКОЙ ПАУТИНЫ...

(30) > делал замеры.
На твоей архитектуре и с твоим набором версий софта, ага.

(35) Успокойся болезный, сегодня тебе никто не подаст... Приходи вчера.

Ладно, понятно. Родаемся и умираем в одиночестве.)))
А ты Acht работай над собой. Хреново выглядишь...

(30) ты зря так просто относишся к проблемме, вот я например всегда думал, что MySql транзакционная база, оказалась, что далеко не всегда, есть сборки (и они активно используются) где транзакции не поддерживаются...

По этому вопрос с блокировками в твоем случае может встать совершенно неожиданным образом и привести или к потерям данных или еще к чему

(33) И не забыть нарисовать отдельный "протокол обмена", учитывающий ситуации, когда одна из сторон еще не запущена/отвалилась...
Вообще сейчас шины обмена модно - дописать приблуду, чтобы драйвер туда отсылал, а 1С вычитывала. Красота!

(37) Обращайся, если что!

(38) Согласен, надо самому копать и конкретно "по месту". Ладно спасибо всем!!! Особенно колхознику ACHTу )))

Вот и закончилось очередное "объясните мне гению, что такое вилка и ложка, а то я вас дерьмом измажу"

Позвольте!
SQLLite - это же встроенный в ODBC микросеовер,то есть два процесса к одной базе данных будут обращаться как к общему файлу!!!
Поэтому,нужно очень внимательно смотреть,какие блокировки ставит пишущий процесс и ставит ли их вообще,так как иначе возможно все,что угодно,вплоть до доступа к неинициализированной памяти,если при записи размер таблиц поменяется.

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

Пишущий блокирует чтение

А читающий запись

(0)Для SQLite конкуренция на запись (пишут по очереди), для остальных случаев все без конкуренции.

Ставим sqliteodbc - http://www.ch-werner.de/sqliteodbc/
И лабаем на 1с код чтения через ADO или ВнешниеИсточникиДанных (выбираем СУБД = "MySQL")