Хранение данных с помощью отдельного приложения C ++ - PullRequest
3 голосов
/ 22 мая 2010

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

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

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

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

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

Спасибо!

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

Ответы [ 6 ]

6 голосов
/ 22 мая 2010

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

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

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

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

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

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

1 голос
/ 22 мая 2010

Ммм ...

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

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

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

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

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

Удачи и приятного путешествия.

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

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

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

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

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

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

1 голос
/ 22 мая 2010

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

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

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

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

0 голосов
/ 22 мая 2010

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

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

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

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

...