C ++ лучший способ хранить массивы или векторы объектов на диске для простой базы данных

0

Я работал над бэкэндом PVR для планирования телевизионных записей, и я пытаюсь найти лучший способ сохранить простую базу данных со всей необходимой информацией. Я собрал прототип ленивого человека (показано ниже), но я не хочу статически выделять огромные массивы, а затем просто выгружать содержимое ram для этих объектов на диск для хранения.

Каков мой лучший вариант, учитывая следующие прототипы ленивой/плохой практики? Как опытный программист решил сделать что-то подобное? Если бы я собирался сделать все это без использования функций toString/fromString, как бы я это сделал?

struct Recording{
    Date date;
    int channel;
    int length; //length in hours, minutes, or seconds
    bool is_interlaced; //if true, denotes that the episode is interlaced
    bool done; //if true, denotes that the episode has been recorded
    bool record_successful; //Currently unused
};

struct TV_Episode{
    struct Recording recording;
    char title[128]; //Episode Title
    char season; //Season number
    char episode; //Episode number
};

struct TV_Show{
    char name[64]; //TV Show name
    char numepisodes; //The number of episodes in the array
    struct TV_Episode episodes[100]; //Array containing airings of a TV show
};

struct Movie{
    struct Recording recording;
    char title[128]; //Movie Title, optionally including the year in brackets
};

struct Recordings_DB{ /*
    * Obviously these types can be done away with using inheritance
    * and the Recordings_DB type can be done away with using a vector.
    * They are just here to illustrate the concept.
    */
    struct TV_Show shows[20];
    struct Movie movies[20];
};
Теги:
storage

3 ответа

0
Лучший ответ

Я действительно работал в мире приставки PVR для 5+ лет, и в моей старой компании мы столкнулись с подобным выбором. Поскольку вы намерены хранить записи PVR на диске, вот некоторые из подходов, которые вы можете предпринять -

  1. Бинарный протокол: сбрасывать типы POD C или C++ в двоичный файл. Для добавления/удаления полей потребуется специальный пользовательский парсер с сложной поддержкой совместимости. Также не читается человеком, поэтому отладка будет болью. Если вы идете по этому пути по скорости или по причине использования диска, по крайней мере, используйте буферы протокола Google в качестве двоичного протокола.
  2. Сериализованный протокол Используйте протокол, читаемый человеком, например XML, JSON для сериализации данных на диск. Легко отлаживается, а также добавлять/удалять поля в схему. Множество парсеров с открытым исходным кодом доступны, например, expat, libxml2, rapidjson, json-c, которые могут сделать тяжелый подъем для вас.
  3. Встроенная база данных. Если ваша система должна поддерживать сортировку, поиск, фильтрацию и т.д., Я настоятельно рекомендую SQlite - легкую базу данных, подходящую для встроенных платформ с собственным интерфейсом C. Этот вариант требует дополнительных усилий по разработке, но будет лучше масштабироваться по мере развития вашей системы.
  • 0
    Спасибо за помощь. Я ценю это. Я давно не программировал, поэтому я довольно ржавый, и в любом случае я никогда не делал ничего, что бы мешало вещам высокого уровня. Есть ли какие-нибудь хорошие учебники по SQL для начинающих, которые вы бы порекомендовали? (Я использовал SQL в прошлом, но это было с PHP, а не с C / C ++)
  • 0
    Подробное руководство по Sqlite - это солидная книга, в которой можно получить глубокие знания и лучшие практики кодирования для интерфейса C SQLite. Я не использовал много учебников, но этот онлайн-учебник выглядит многообещающе.
Показать ещё 1 комментарий
0

Это, вероятно, будет немного раздражать, так как вам нужно будет написать собственный код сериализации (tostring/fromstring) или принять библиотеку. Если вы пишете свои собственные, обязательно подумайте о том, где вы добавляете поле в одну из ваших структур, но хотите иметь возможность читать в старом формате; планирование вперед помогает в решении этой проблемы.

Два варианта, которые вы можете рассмотреть, это библиотека буферов протоколов Google (вы должны определять буферы протокола вместо структур, а затем вы можете просто сериализовать записи верхнего уровня) или SQLite (вам нужно будет написать некоторый базовый SQL для заполнения полей, но вы также получаете индексирование и транзакции). Если ваша база данных никогда не будет более нескольких тысяч записей, я рекомендую использовать буферы протокола, поскольку SQL не принесет вам большой пользы. Оба являются достаточно компактными, простыми библиотеками, которые хорошо поддерживаются.

0

Если вы не хотите статически выделять массивы, то почему бы не использовать std::string и std::vector? Вы получаете динамическое распределение до нужного размера, и вы не получаете ограничения на максимальный размер. Это победа.

Также не используйте char для целых значений. Такой зажим щипков не нужен. Он вернется, чтобы укусить вас. Помните Y2K? Верьте или нет, у современных компьютеров много памяти и дискового пространства. И во многих случаях, из-за заполнения, вы все равно не сохраняете память.

  • 0
    Использование char было больше для ударов, и снова играла с кастингом. Тем не менее, я имел в виду сохранить, как в, сохранить на диске. Кроме того, массивы char были больше для того, чтобы я мог написать схему, которую я мог бы, если бы действительно хотел, просто сбросить все пространство памяти на жесткий диск и заставить его работать, пока я искал лучший вариант (отсюда и этот пост)

Ещё вопросы

Сообщество Overcoder
Наверх
Меню