Эффективно хранить легко анализируемые данные в файле? - PullRequest
0 голосов
/ 05 августа 2010

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

Из моего ограниченного опыта без базы данных я вижу несколько вариантов, все с проблемами

  • CSV - технически я мог бы сделать это, и это очень легко.Однако, разбор был бы проблемой, и тогда это было бы плохо, если бы я хотел добавить столбец.Многоязычная поддержка сомнительна, в основном собственные пользовательские парсеры
  • XML - это идеальное решение со многих сторон, за исключением случаев, когда речь идет о синтаксическом анализе и накладных расходах.Это много тегов и будет генерировать гигантский файл, и анализ будет очень много ресурсов.Однако практически каждый язык поддерживает XML
  • JSON. Это промежуточная ступень, но я не очень хочу этого делать, так как это неудобный синтаксис, а синтаксический анализ не тривиален.Языковая поддержка ненадежна.

Так что у всех есть свои недостатки.Но что будет лучше, если вы стремитесь к языковой поддержке и небольшому размеру файла?

Ответы [ 8 ]

3 голосов
/ 05 августа 2010

Как насчет sqlite ?Это позволит вам встраивать «БД» в ваше приложение, но не требует отдельного бэкэнда БД.

Кроме того, если вы в конечном итоге будете использовать бэкэнд БД позже, переключение должно быть довольно простым.

Если это не подходит, я бы предложил одно из хранилищ, похожих на DBM, для поиска по значению ключа, такое как Berkely DB или tdb.

1 голос
/ 05 августа 2010

Если вы просто используете основы всех этих форматов, все парсеры тривиальны. Если CSV является опцией, то для XML и JSON вы говорите о блоках пар имя / значение, так что здесь нет даже рекурсивной структуры. json.org поддерживает практически любой язык.

Это сказал.

Я не вижу, в чем проблема с CSV. Если люди пишут плохие парсеры, то тоже плохо. Если вы беспокоитесь о совместимости, примите модель CSV по умолчанию из Excel. Любой, кто не может разобрать CSV из Excel, не сможет продвинуться далеко в этом мире. Самая слабая поддержка, которую вы найдете в CSV, это встроенные переводы строк и возврат каретки. Если ваши данные не имеют этого, то это не проблема. Только другая проблема - это встроенные цитаты, которые избегаются в CSV. Если у вас их тоже нет, то это еще более тривиально.

Что касается "добавления столбца", у вас есть проблема со всем этим. Если вы добавите столбец, вы сможете переписать весь файл. Я тоже не вижу в этом большой проблемы.

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

0 голосов
/ 05 августа 2010

Я бы сказал, что если вы хотите хранить строки и столбцы, вы должны использовать БД. Причина проста - изменение структуры любым подходом, кроме СУБД, потребует значительных усилий, и вы упомянули, что хотите изменить структуру в будущем.

0 голосов
/ 05 августа 2010

Если вы вынуждены использовать плоский файл, почему бы не разработать свой собственный формат? Вы должны иметь возможность настраивать накладные расходы и настраивать столько, сколько хотите (что хорошо, если вы анализируете много данных). Записи данных будут иметь фиксированную или переменную длину, есть преимущества в том, чтобы принудительно вводить некоторые записи фиксированной длины, но вам нужно будет создать метод для разделения обоих. Если у вас есть разные «типы» строк, запишите все строки каждого типа в чанке. Каждый кусок строк будет иметь заголовок. Используйте один заголовок для описания типа чанка, а другой заголовок для описания столбцов и их размеров. Определите, как вы будете использовать заголовки для описания каждого куска.

например (H - заголовок, C - описание столбца и D - ввод данных):

H Phone Numbers
C num(10) type
D 1234567890 Home
D 2223334444 Cell

H Addresses
C house(5) street postal(6) province
D 1234_ "some street" N1G5K6 Ontario
0 голосов
/ 05 августа 2010

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

Если вы хотите изменить порядок / использование полей, вы можете добавить строку заголовка. то есть первая строка имеет названия столбцов. Это может быть полезно, когда вы пытаетесь прочитать данные.

0 голосов
/ 05 августа 2010

Когда мне нужно было подобное решение, я записывал простое представление данных с префиксом длины. Например, «Привет» будет представлен как (в шестнадцатеричном) 02 48 69.
Чтобы сформировать строки, просто вложите эту операцию (сначала число - это число полей, а затем полей), например, если поле 0 содержит «Привет», а поле 1 содержит «abc», то это будет:

Num of fields   Field Length   Data    Field Length   Data
02              02             48 69   03             61 62 63

Вы также можете использовать первую строку в качестве имен для столбцов. (Я должен сказать, что это своего рода серверная часть БД).

0 голосов
/ 05 августа 2010

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

Если это неструктурированные данные, которые могут нуждаться в некотором анализе, я бы пошел на JSON.

Если это структурированные данные, и вы предполагаете когда-либо делать какие-либо запросы к ним ... Я бы пошел с sqlite.

0 голосов
/ 05 августа 2010

JSON - это, вероятно, ваша лучшая ставка (она легкая, быстрее разбирается и информативна, поэтому вы можете добавлять новые столбцы с течением времени). Вы сказали, parsable - вы имеете в виду использование Java? Существуют библиотеки JSON для Java, которые облегчают большую часть работы. Существуют также различные легкие базы данных в памяти, которые могут сохраняться в файле (в случае, если «не вариант» означает, что вам не нужна большая отдельная база данных)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...