Java XML против SQL против пользовательского хранилища данных - PullRequest
0 голосов
/ 23 января 2012

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

Мои конкретные потребности:

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

Я рассмотрел XML, который в большинстве случаев дает сбой по второму и третьему пунктам,но также немного о первом пункте (я не уверен, насколько масштабируем XML на самом деле, я не проводил никаких тестов).

Я также рассмотрел SQLite, но для этого требуется сторонняя библиотекаработать должным образом с Java (насколько мне известно), а также не работает в третьей точке, так как прямой доступ невозможен.

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

Примечание: я знаю, что это возможный дубликат Лучший способ хранения данных для небольшого персонального приложения (база данных SQL, XML или другой тип файла) , но предпочтительным ответом является SQLite, и есть разница между C ++ и Java в том, что касается SQLite, поэтому я решил этот вопросдостаточно отличается.Поправь меня, если я ошибаюсь.

Ответы [ 3 ]

1 голос
/ 23 января 2012

Доступ к БД через ODBC делает код менее зависимым от технологии БД, так как большинство баз данных имеют драйверы ODBC.

1 голос
/ 23 января 2012

Для чего-то вроде реляционных данных я бы предпочел ядро ​​базы данных H2. HSQLDB тоже может это сделать. Он сможет запрашивать данные легче, чем XML или JSON. Думайте об этом как о продвинутом SQLite, который может работать в режиме сервера и легко доступен для внешних инструментов (на самом деле поставляется с H2).

Посмотрите на neo4j , если ваши данные построены на графике.

0 голосов
/ 16 марта 2012

В итоге я выбрал специальное JSON-подобное решение, так как для проекта было не важно, чтобы файл использовал стандартизированный формат.

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

...