Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
01.09.2004, 18:04
|
|||
|---|---|---|---|
|
|||
Низкоуровневая БД для MCU |
|||
|
#18+
Здравствуйте, Господа. Первое моё сообщение на sql.ru Сам я с БД знаком мало - это вероятно самое слабое место в моём программерском education. Однако появилась у меня задача. - Есть микроконтроллер: памяти немного, с производительностью всё ещё хуже. Пишу модуль на C. Модуль должен быть оч. хорошо переносим на др. платформу - Есть разнородные физические объекты, информацию о которых надо хранить в различных видах памяти (eeprom, flash, RAM) - EEPROM отличается тем, что у неё ограниченное число циклов перезаписи (а значит к некоторым объектам нужно по реже обращаться, если можно) - Нет даже malloc - т.е. будет заранее выделятся фикс. объём памяти, который затем будет побайтово заполнятся по мере необходимости Есть выбор: 1)Либо хранить всё в виде последовательности записей фиксированного типа (либо int32, либо string, либо ещё чего-нибудь) (но надо понимать, что это всё равно будет не реляционная Бд: никаких индексов, линков полей в таблицах и пр. не будет). Тогда каждый реальный объект может описываться как одной, так и несколькими единицами данных в БД. Число обращений максимально. Код не красивый - мало похоже на ООП подход . Функции: get_integer(ID), get_string(ID), get_alarm(ID) Но легче осуществлять поиск, и как говорят опытные люди, легче модифицировать содержимое БД в будущем. Тем более, что возможно придётся с PC напрямую подменять содержимое БД путём обращения к области памяти, в которой хранится БД. 2) Либо хранить всё по блокам. Каждому реал. объекту - в соотвестствие ставим одну запись в БД. Тогда работать удобнее, ближе к ООП (чего мне очень хочется), меньше обращений к eeprom. Функции: get(ID,void *pObject) Что выбрать? Где найти src для какой-нибудь допотопной нереляционной БД? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2004, 14:40
|
|||
|---|---|---|---|
Низкоуровневая БД для MCU |
|||
|
#18+
Подобного рода задачи решали при проектировании сначала Newton PDA, потом PAlm. Решили, надо сказать, неважно. Если разработка ведется для микроконтроллера и по памяти есть ограничения, то требование >Модуль должен быть оч. хорошо переносим на др. платформу само по себе некорректно. ИМХО проще всего написать что-то свое, уйдет на это месяц напряженной работы, зато оно будет хорошо соответствовать задаче. "Реляционность" БД вообще мало отношения имеет к вопросу. В частности реляционная модель вовсе не предполагает существования индексов или "линков" Washington Irving ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2004, 22:33
|
|||
|---|---|---|---|
Низкоуровневая БД для MCU |
|||
|
#18+
--допотопной нереляционной БД? зачем же допотопной. Пользуйтесь XML - легко модифицируемая на любой платформе. НЕту правды реализаций QueryXML на всех платформах. Но если не заморачиваться с SQL запросам, а пользоваться DOM моделью - то самое то для встаивамых систем и удовлетворяем вашим условиям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
08.09.2004, 11:07
|
|||
|---|---|---|---|
Низкоуровневая БД для MCU |
|||
|
#18+
Нуу , какой XML на микроконтроллере... По моему лучше всего определить фиксированную структуру данных и хранить ее в выделенной памяти, при этом держать битовый массив по длине блока памяти где проставлять флаги - занят блок или удален, уже ускорение поиска. Во вторых индекс можно создать в простом массиве отсортировав допустим первые три символа какой либо строки - ключа, еще большее ускорение поиска. Т.е. в принципе все действия в рамках оптимизации работы с массивами (разреженными массивами). Можно посмотрет и в сторону связанных списков. Написать собственный менеджер памяти именно для этой задачи (управления структурами данных) в общем поле для деятельности широко, задача интересна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=16&tablet=1&tid=1348213]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 247ms |
| total: | 343ms |

| 0 / 0 |
