Все зависит от того, какие типы данных в полях, постоянные ли они от строке к строке и много ли 'пустых' значений или точнее, значений с переменной длиной (строки например).
Плюс, каким образом нужно проводить поиск данных, т.е. очевидно что читать все тебе последовательно не нужно, а значит нужно делать выборку по какому то условию.
Ну еще, зависит от того, готов ли ты на накладные расходы потратить место на этой карте памяти.
Теперь, если потелепатствовать, то используй простой формат с фиксированными размерами под данные.
Проще говоря, фиксируешь размер памяти на каждую ячейку данных, фиксируешь количество и типы колонок в строке и получаешь классическую таблицу.
Данные хранишь в файле так, как они хранятся в памяти ардуинки (особенно если они больше нигде использоваться не будут, ну или заранее продумай в каком формате числа будешь хранить
BE/LE.
Каждая 'строка' в файле у тебя будет фиксированной длины (можно еще и выровнять на количество байт степени двойки, что оптимизирует операции умножения вычисления позиции, для ардуинки может быть актуально под какие то задачи) и разделители не нужны. Т.е. по номеру строки и номеру колонки можно высчитать смещение данных в файле простым умножением и сложением.
Если нужны запросы по значению, пиши рядом индексный файл, где храни последовательность пар хеш_значения->номер_строки_в_файле, при этом если происходит коллизия, делай в этом файле еще записи с тем же хешем (рядом, чтобы пришлось делать только два лишнего чтение). Значения сортируй по хешу, поиск нужного значения делай тупой дихотомией (метод деления пополам или бинарный поиск) - как нашел значение, читай записи вверх, а потом вниз от него, пока есть коллизия хеша.
Этот подход очень прост в реализации, не требует оперативной памяти от слова совсем (только буферы на работу с файловой системой), при хорошо подобранном хеше с малыми коллизиями, даст 'логарифм' чтений при поиске данных по значению, но не дает красиво править индекс и индексные данные (так как индекс нужно будет сортировать) т.е. подходит там где сами индексы и данные будут готовить на нормальном устройстве без дефицита ресурсов.
