Почти съм сигурен, че няма ама все пак да питам... Трябва боза за данни за микроконтролер. Демек нещо дето да може да поддържа да кажем 10-100к записа, да ги индексира по 2-3 индекса, тъй че да може записите да се обхождат в една или друга подредба, или пък да се търси бързо по един или друг критерий.

А и естествено това да се търкаля в микропрофесор, демек да не ми иска повече от 10 айде 20к RAM. Щото има разни DB-та ама под ембеддед разбират няколко меги рам, и няколко стотин К код... е немам толкоз

SQLite не можеш ли го подкара .. щом по телефончетата го търкалят ..... въпреки че вече телефончетата са си компютърчета де

SQL lite не знам длаи е за ембедед, телефоните са много далеч от ембедед ми се струва вече, или поне това което аз разбирам като ембедед. SQL Lite има и един сериозен проблем, дори на РС се оказва че един запис отнема почти секунда. За да го оптимизират са направили опция да буферираш записи и да ги записваш наведнъж, обаче това си има и своите недостатъци, и то не малко.

500К code size ми е един порядък в повече...

Пък и не е точно това което ми трябва. В смисъл бозите имат общо взето 3 нива:
1) физически как и на какво записва, т.е. да не се омазва
2) логически как се подреждат, организират и индексират, тъй че всичко да се намира с минимален брой сийкове или диск операции.
3) Приложно ниво - как се представят полета, формати, конвертирания, абстракции, атомичност бля-бля...

Та SQL-те предимно наблягат на приложното ниво, а орязаните версии почти нямат физическо ниво, т.е. искат да им осигуриш някакъв файл и си е твой проблем какво става ако спреш тока по време на писане по файла...
На мен ми трябват първите 2 нива, като е желателно да няма нужда от файлова система, директно да се монтира върху сд-карта. В краен случай физическото ниво мога и сам да го направя, стига логическото да пасва за работа на сектори. Всъщност логическото ми е най-големия дерт, че иска повечко математики, балансирани дръвчета и тем подобни алгоритми... Приложното ниво не ми е нужно толкова. мога да мина и без такова.

http://www.mcobject.com - май имат разни безплатни неща, но принципно са платени
http://www.garret.ru/cpp.html - това е много добро - ще трябва малко да си го пипнеш за да няма депендасита към разни външни библиотеки (ако въобще има де)

Ползвал съм ги, но не за ембедед, а за .NET C# - трябваше ми лек ОРМ със spatial index - направих редактор на диаграми (нещо като Визио) с 1 милион елемента на екрана, доста е солидно, съвсем малко бъгове имаше.

мерси, изглеждат интересни... но едното е за РАМ, другото на джаба/Ц#.... няма пълно щастие, ще си цапам ръцете явно

виж на руснака нещата - гигабейз и фастдб - те са персистент - т.е. записват на диск
доколкото помня организацията е по страници, и във всяка страница е пълна с данни или индекс и т.н. т.е. това което трябва да портнеш е да четеш/пишеш тези страници във твоя сторидж
индексите ги прави с бтрее - т.е. читаво е
отделно има транзакции, по сложни (ала СКЛ) заявки, ОРМ - т.е. с малко макроси в Ц++ живи обекти се сериализират в базата данни и коато потрябват се четат
абе разгледай го - ще ти свърши работа

хм... изравям темата защото чак сега опря яйцето до...

Значи бях си помислил че ще ползвам "нещо" от нещата на руснака, обаче няколко дена се дзверя... и пак се дзверя.. и абсолютно нищо не мога да скрабна
Организацията му е просто за компютър и не става за bare matal. Да не говорим за стила му на писане, последно исках да взема само кода за хеширане, ама то така е написано че предпочитам да не го ползвам...



Та... продължавам да търся нещо което отговаря на следните условия:

На физическо ниво:
1. Да не изисква файлова система отдолу. Демек не искам както руснака да отваря каквито му скимнат файлове и да пише по колкото си иска в тях.
2. Да има транзакции и възстановяване. Демек да може да си оправи бакиите в случай че е спирал тока и са останали недозаписани неща.
3. Да е просто, имам предвид много малко код и много малко RAM.

На логическо ниво:
Съвсем проста база данни - програма минимум само една таблица и само един индекс.

Всъщност основният проблем е изграждането на индекса... Мога да ползвам хеш или някое от разните дървета, не е критично толкова. Просто не ми се щеше да го пиша аз

Трябва да си поразровя из архивите, навремето писах такова нещо под дос - с транзакциите му и т.н. ама тогава още пишех на Ц++ - на теб няма да ти е проблем де По време оно Borland C++ 3.1 нямаше подръжка за ексепшън хендлинг, та го иземулирах с макроси и set/longjump - т.е. дивотия си е ... за съжаление май точно тези архиви са ми в БГ - т.е. брой го някъде по великден

А кое те затормози в на тоя пич сорсовете? Не че съм ги дълбал, ама мисля че би трябвало с малко ръчкане да се подкарат за ембедет система. Всичко му работи върху btree, а там като нагласиш страницата да ти пасва с flash-а и горе долу си готов.

Първо написани са супер неразбираемо, няколко дена изгубих да ги разучавам, то са едни макроси, едни дивотии... С две думи страх ме е да почна да ги редактирам. А лошото е, че директно не ми вършат никаква работа.
Да кажем индексирането - направил го е опционално, ОК. Но има пример само за стринг и е оптимизирано за стрингове. Няма лошо, даже си е оставил възможност да се конфигурира размера на хеш блоковете, броя на сегменти и т.н.. На първо четене изглежда супер (и аз се подведох). Обаче при мен за съжаление полето по
което ще се прави индекса по принцип не е задължително. Естествено ако клиента реши че няма да въвежда това поле индексът няма смисъл, но аз няма откъде да знам. Той може да въведе за 5 записа, за други 50 да не въведе, негова си работа... Въпросът е че ако е въвел и пусне търсене, трябва да мога да намеря записа в разумно време (не да изръчкам 4GB сд-карта примерно). От друга страна, ако не го въведе може да се получат хиляди записа с един и същ индекс. А това ще счупи хеш-а на руснака. Поне доколкото виждам из сорсовете, динамично се определя частта от ключа дето индексира блока. Като станат много позициите в един блок прави по-прецизно адресиране и се надява че така хешовете ще се пръснат в различни блокове. Но при един и същ ключ както и да си играеш с адресирането всички ще се натискат да са в един и същ блок, който рано или късно се пълни и сме до там...
Всъщност то май няма решение с хеш изобщо като се замисля... В най-добрия случай ще е супер тромаво.

Транзакциите му също не ми вършат работа. Отваря си един файл човека и там си прави бакъп на секторите които променя. В края на транзакцията ако всичко мине трие файла. Стандартно... само че разчита на файловата система отдолу, която ако е с някакъв надежден журналинг ще стане, ама при мен няма такива екстри

Абе с две думи от minidb-то нищо не ми върши работа. Другите му продукти пък са прекалено тежки, просто на мен ми трябва нещо наистина супер просто...

Помня, че моя дизайн беше доста прост до едно време, след това се усложни заради бтрее - а то няма много начини да направиш индекс с вмъкване/триене на произволна позиция съобразен със спецификата на външна памет. Първо имах един обект който работеше във файл със страници по 4к или колкото го конфигурираш (Накрая страницата ми беше около 100-на байта за да може да се навре всичко в 640к). Та този обект имаше един роот (голям проблем ако си на флаш където не може да презаписваш един и същи сектор ей така) в който общо взето имаше списък на освободените страници. Т.е. като потрябва нова страница първо се гледа дали има освободена и ако няма се раздува файла. Върху този обект направих бтрее което общо взето беше индекс по примари кей на втори файл от тип рекорд със същинските данни - всеки път като се налагаше да се вмъква/трие някакъв елемент, всички страници които се променят се копираха в нови и чак когато всичко е записано на диска и флушнато роот страницата се променяше да сочи към новата структура и се освобождаваха променените страници, т.е транзакция. Това си беше един сложен рекурсивен алгоритъм. Четенето беше проста работа - то си е дърво. Направих промяна с класическото бтрее като данни се пазеха само по листата, а в междинните нива се помнеше само връзка към по долното ниво. Та, това нещо работеше (и даже май още се ползва от бившия ми съдружник) доста стабилно, почти не сме имали проблеми със скапани бази данни а имахме стотици клиенти из цяла България - продавахме ПОС за супермаркети.
Доста години по късно прочетох нещо интересно подобно на това което бях направил - как е реализирана CouchDB - това май е идеалната база за флаш, поне като концепция. В нея не се трие нищо и не се презаписват данни. Всичко се добавя към края на файла, като във всяка страница която се добавя е записан указател към предишния руут сектор на дървото, като транзакцията приключи се записва новия роот който сочи сам към себе си. Така ако транзакцията се омота, просто отиваш на края на файла, прочиташ от него един сектор и отваряш руута на про предната транзакция - т.е. правиш автоматичен роллбак. Този дизайн позволява да се направи нещо като машина на времето - по всяко време може да гледаш базата данни както е била към произволен момент в миналото. Разбира се с времето става доста непрактично базата само да расте, решението е да се прочете всичко елемент по елемент и да се запише в една нова база - т.е. гарбидж колектинг

Малко дълго се получи, но дано ти свърши работа ако решиш да правиш всичко сам. На руснака нещата са доста близки, то между другото дори и големите SQL сървъри се правят по доста подобен начин, просто си е сложно. Няма начин да го преправиш без да положиш усилия да го разбереш преди това - а това е едно от най трудните неща за програмисти с голямо его И аз съм от тях де ...

Това CouchDB е твърде дебела работа... аз търся нещо съвсем елементарно, дето евентуално да мога да го вкарам и бутстрап, демек няколко KB код

Не искам поддръжка на релации, формати и прочие. Просто да може да пише записчета на SD карта и евентуално да може да ги индексира по един индекс, така че като се наложи търсене по тоя индекс да не се налага изчитане на гигабайти...

Ебаси, никой ли не ползва SD карта с неголям контролер? Навсякъде гледам са стъпили на някакъв смотан FAT... няма нито надеждност, нито бързодействие. Ех, вече при по-големите ембедед системи има разни решения, ама чак пък да слагам лайнукс заради едната просто SD карта...

Вече продават SD карти с линукс в тях.

Самия CouchDB въобще не е за ембедед - голямо прасе е, писано на ерланг. Просто в него има някои неща които пасват за твоя случай - не да го ползваш, а да взаимстваш някоя идея ако решиш да си правиш всичко сам. Трудно ще вкараш нещо кой знае какво в по малко от 10кб - всъщност може и да стане де, проблема не е чак толкова сложен, че да иска сложно решение - то предполагам и точно това не ти дава мира и на теб
А я кажи ако не е тайна какви са ти очакванията за данните които трябва да обработваш? Брой записи, големина на ключа по който ще се индексират, големина на един запис и т.н. Като нищо може да се окаже, че не ти трябва бтрее и разни сложни индекси, транзакции и прочее ...
Едит: Данните дали случайно няма да идват сортирани - т.е. ако сортираш по ред на вкарването им, или по дата ... ключовете дали ще са уникални или не. Всички тези неща имат значение за да избереш правилните алгоритми и структури от данни ( = програми както е казал чичко Вирт )

Проблемът е че не можах да намеря подробности относно организацията. Има хиляди документи как се ползва и т.н. но нищо не видях на тема имплементацията им на ниско ниво.


Преди всичко трябва да си свърша работата... при това бързо, че много протаках. Така че ако намеря готово или почти готово решение ще е супер. Ако пък е малко като код ще е още по-добре. Не че не може и 50к, обаче 5-10к ще даде повече възможности. Примерно ще може да се вкара в бутстрапа и SD картата да се ползва за ъпгрейд на фирмуера..


Не е чак тайна, по-скоро не искам да бъде обвързано с конкретен проект. Практиката показва че писането на една боза отнема време, да не говорим че и след това минава доста време докато се изчистят бъгтериите. Примерно имаме си решение за дейтафлаш и си го ползваме във всякакви проекти. Долу-горе имаме решение и за лог-система на SD-карта.
В случая обаче трябва индексиране. По-точно трябва да може да се индексира, ако въвеждат индекси, но трябва да не се бъгва и ако не ги въвеждат
Иначе както казах трябва да е стандартна ди-би таблица с един индекс. Броят на записите - колкото - толкова. Все пак е SD карта и мястото е 1-2-4 GB. Някак си ще е тъпо да кажа че не искам повече от 10к записа след като има място за 100к. Размерът на един запис в конкретния проект може да е фиксиран, но няма да се разсърдя ако бозата поддържа променлив размер
Индексът е стринг за съжаление и записите определено няма да идват сортирани.

В идеалния случай трябва да може да се поддържа нещо от сорта на склад или счетоводство. Хайде склад да кажем - първо имаш една таблица с номенклатурите, т.е. материалите дето складираш. Постоянно се добавят нови, така че въвеждането става е неопределен порядък. Бозата си прави някакъв номенклатурен номер, но материалите може да имат име, по което също трябва бързичко да се рови из таблицата. После има друга таблица с движенията - взел Петко, дал Петко...
СЛед това имаш два вида справки - хронологични и аналитични. Хронологичните са по втората таблица от запис (дата) до запис (дата). Аналитичните са малко по-сложни... пак има обхождане от дата до дата, но салдата се натрупват в нова временна таблица. Накрая се получава - в склада са излезли/влезли толкоз мотики за тоя период, толкоз чукове, толкова отверки.. Ех, ако имаш памет най-добре но в общия случай броя на номенклатурите е в "хиляди" и надвърхля възможностите на малък контролер... Съответно представи си как се обхожда движението да кажем една година назад и за всяко движение се прави сийк във временната таблица.

Та така, това е долу-горе пример за възможностите дето ми трябват. Както вероятно се сещаш картата ще е разцепена на няколко дяла, колкото таблици са нужни... Евенуално и журнали, освен ако не се вкарват вътре в таблиците.