Эффективно хранить легко анализируемые данные в файле?

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

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

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

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

источник

2010-08-05 TheLQ

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

указано.

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

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

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

источник

2010-08-05 04:06:25

Если бы я использовал XML, я мог бы добавить элемент, просто добавив новый тег. Я забыл, что CSV был импортирован в электронные таблицы excel. – TheLQ

Тогда ваш XML не соответствует. Теоретически, XML-файл представляет собой один элемент с потенциально большим количеством детей этого корня. Не сказать, что это невозможно, и другие делают это, просто говоря, что в итоге вы являетесь файлом с несколькими элементами XML, а не файлом, который является соответствующим XML-документом. –

T – TheLQ

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

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

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

источник

2010-08-05 04:04:00

SQLite - это вариант, но я действительно хотел иметь плоское хранилище файлов, а не только db в файле. – TheLQ

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

источник

2010-08-05 04:08:33

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

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

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

источник

2010-08-05 04:15:00 WOPR

Вкладка с разделителями кажется ужасной, когда вы добавляете строку, которая на один символ длиннее, чем остальная часть столбца. И могут быть вкладки в данных. – TheLQ

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

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

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

источник

2010-08-05 04:27:41 Dani

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

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

источник

2010-08-05 06:37:37

Итак, у меня было бы 3-4 пустых столбца в конце каждой строки? – TheLQ

Я бы предложил, чтобы синтаксический анализатор предположил, что если он пытается читать поля, которые не присутствуют, они считаются пустыми. –

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

например (Н заголовок, С описания столбцов и 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

источник

2010-08-05 07:05:57

Thats doable Я думаю, но я искал стандартное место для хранения – TheLQ

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

источник

2010-08-05 11:01:44

Эффективно хранить легко анализируемые данные в файле?

ответ

Смежные вопросы