Хранение данных с помощью отдельного приложения C++

Question

Я работаю с Apache, PHP и MySQL для веб-разработки и локальных приложений. Последние пару лет я медленно изучаю C++ и хочу создать приложение этим летом. В частности, я хочу создать "библиотечное" приложение, в котором я могу хранить информацию о книгах, компакт-дисках и записях, которыми я владею. Я знаю, что этот тип приложений существует, но я хочу изучать C++, и это кажется хорошим способом сделать это.

Вот несколько вопросов:

1. Можно ли создать отдельное приложение, для которого не требуется база данных для хранения данных?

2. Если ответ на вопрос № 1 выше - "да", будет ли хорошей идеей сделать это для приложения, которому потенциально может понадобиться управлять большим количеством данных?

3. Какие варианты хранения данных вы бы порекомендовали для использования с приложением C++?

Спасибо!

Обновление Ну, было много хороших ответов на это. Это такой замечательный сайт с таким количеством участников. Оказывается, мне сейчас может не понадобиться идти по пути C++. Теперь я понимаю, что меня больше всего интересует написание приложения, которое может функционировать как "библиотечная" организационная система больше, чем я хочу заниматься C++. Спасибо всем за ваши ответы!

Answer 1

Можно ли создать отдельное приложение, для которого не требуется база данных для хранения данных?

Да, вы можете сделать какой-то специальный формат файла для хранения данных.

Если ответ на вопрос № 1 выше - "да", будет ли хорошей идеей сделать это для приложения, которому потенциально может понадобиться управлять большим количеством данных?

Это не очень хорошая идея, если вы действительно не хотите узнать о хранении данных в структурированном файле.

Какие варианты хранения данных вы бы порекомендовали для использования с приложением C++?

Я бы посмотрел на SQLite. Это база данных, но ей не нужен отдельный движок.

Answer 2

Если вы не хотите использовать базу данных, вы можете сохранить свои данные в файл (или, возможно, более одного). Если так, то вопрос, вероятно, в том, какой формат файла является лучшим? Ответ зависит от различных факторов:

1) Быстрый доступ, небольшой размер и простота разбора? Ответ - "двоичные данные". Просто напишите ваши данные прямо как есть в выходной файл, используя fwrite. Есть два недостатка: файлы не читаются человеком, и поддерживать разные версии неудобно. Если прочитанные вами данные не совсем соответствуют вашим ожиданиям, вы быстро столкнетесь с проблемами.

2) удобочитаемый и простой в обслуживании? Вот для чего нужен XML. Есть готовые парсеры вроде tinyXML, которые являются отличными инструментами для записи данных в файл. Недостатком является то, что написание процедур загрузки / сохранения занимает больше времени (много случаев).

3) Библиотеки, которые делают эту работу за вас. MFC предоставляет класс CArchive, но есть другие и, вероятно, лучшие инструменты для этого.

Answer 3

Хммм...

Конечно, вы можете сделать это.

То, о чем вы говорите, - это отступление во времени до того периода, когда СУРБД стала успешной. Это не сложно сделать, но вы можете взять некоторые уроки:

1. Прежде чем вы начнете кодировать - или, по крайней мере, прежде чем писать код доступа к данным, проектируйте свою базу данных так, как если бы вы собирались использовать базу данных - какие данные вам нужны? Можете ли вы уменьшить количество необходимых вам атрибутов ("полей")? Каковы общие черты между типами носителей в вашей библиотеке? и т.п.
2. Рассмотрите возможность использования деревьев каталогов и имен файлов в качестве специальной структуры хранения. Это предоставит данные непосредственно в руки утилит командной строки, если вам нужно или вы хотите управлять данными за пределами возможностей вашей программы. Например, все книги могут находиться в подкаталоге books, и в этом случае вы можете использовать ISBN или заголовок в качестве имени файла. Я ищу вещи, которые будут естественным образом сортироваться по имени файла, используя ls, dir или что-то еще, что использует ваш CLI.
3. Другим хорошим выбором было бы поместить его в формате XML. Возможно и то и другое - используйте иерархию каталогов для общего макета данных и поместите данные записей библиотеки в простые файлы в формате XML. Это может оказаться полезным в какой-то момент.
4. Положите данные ТОЛЬКО в текстовом формате в виде строк - без двоичных данных! Это важно, опять же, для возможности доступа / манипулирования данными вне вашей программы.
5. При такой стратегии вы можете использовать системные инструменты, такие как grep, sed, lex и т. Д., Чтобы выполнять совершенно незапланированные действия с данными в случае необходимости.
6. Имейте функцию - или напишите отдельную программу для чтения - которая обходит вашу "базу данных" и выводит все ее содержимое в виде простого текста, по одной строке на запись. Возможно, у вас есть опции, которые сообщают ему, какой тип носителя выводить и т. Д. Кроме того, включите флаг, который позволяет вам устанавливать разделитель, используемый между атрибутами для вывода - разделенный запятыми типичный выбор, но вам также может понадобиться только пробел, возврат каретки, новая линия или что-то еще. Если вы сделаете его необязательным флагом, чтобы позволить пользователю использовать что-либо и указать ваши любимые настройки по умолчанию, все будет в порядке.
7. Модульный код, чтобы вы могли заменить стратегию хранения позже, если захотите, и вам не придется заново взламывать всю программу. Вы можете даже предоставить несколько стратегий хранения.

Это должно сделать это.

Обратите внимание, что объем данных, которыми вы будете управлять с помощью современного компьютерного оборудования, вряд ли когда-либо станет проблемой производительности или пространства, поэтому не беспокойтесь о сохранении нескольких байтов - это не стоит хлопот.

Удачи, и наслаждайтесь поездкой.

Answer 4

1. Да.
2. Это может быть, но если ваши потребности не являются более специализированными, чем они кажутся, менеджер базы данных общего назначения, вероятно, будет лучшим вариантом.
3. Для чего-то подобного, я бы подумал об использовании одного из (многих) встраиваемых менеджеров баз данных, которые доступны.

Учитывая, что вы (очевидно) делаете это в первую очередь для самообразования, а не для реального использования, возможно, имеет смысл написать код без менеджера баз данных для управления хранилищем. Написание всего кода по собственному желанию (с некоторой осторожностью) обычно приводит к несколько большей скорости, за счет значительной дополнительной работы и, как правило, некоторой потери гибкости. Самая большая проблема с точки зрения обучения заключается в том, что значительная часть того, что вы изучаете, делает это только в довольно узких условиях (т. Е. Для большинства типичных приложений вы захотите использовать менеджер баз данных, поэтому обучение без редких выигрышей).

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

Answer 5

1. да
2. Это зависит от данных, "большое количество данных" является относительным, вы можете обнаружить, что информация о 1000 книгах может храниться в нескольких МБ, тогда было бы излишним хранить ее в БД, если только это не легкая БД, такая как SQLite
3. Я бы рекомендовал придерживаться простого текстового формата, такого как CSV или XML.

Ради изучения, вам очень поможет НЕ использовать механизм БД, если вы не хотите изучать SQL и реляционный дизайн БД. С другой стороны, использование механизма БД сделает разработку быстрее и проще, потому что она создаст индексы для различных частей данных, чтобы помочь вам осуществлять поиск легко и эффективно.

Так что решать вам.

Answer 6

Я также рекомендовал бы SQLite.

С их веб-страницы:

"SQLite - это программная библиотека, которая реализует автономный, безсерверный, транзакционный механизм баз данных SQL с нулевой конфигурацией. SQLite - это наиболее широко развернутый механизм баз данных SQL в мире. Исходный код SQLite находится в открытом доступе".

"Думайте о SQLite не как о замене Oracle, а как о замене fopen()"