Сохраняется ли XML / CSV / Другое через хранилища / службы / другое?

Question

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

В настоящее время у меня есть репозитории CSV, XML и SQL, которые занимаются импортом / экспортом данных. Репозиторий XML сохраняет переданный объект в файл. В настоящее время именно там хранится отображение объекта в XML, следовательно, это единственное место, которое знает об этой структуре (аналогично, другие хранилища для их соответствующих структур).

Теперь, когда я хочу сохранить XML в базе данных, я начинаю подвергать сомнению эту архитектуру. Чтобы выполнить вставку в базу данных, структура XML должна быть доступна из репозитория SQL (например, данные в других столбцах можно вставлять в БД вместе с XML). Это заставляет меня задуматься о том, должно ли представление XML храниться в самом объекте, на уровне службы или где-то еще.

Каковы наилучшие способы реализации решения этой проблемы?

ОБНОВЛЕНИЕ: уточнение моего вопроса. Репозиторий XML в настоящее время сохраняется в файл. Мне кажется, что это неправильный уровень для хранения знаний о структуре XML, так как тогда у меня нет гибкости в сохранении представления XML на любой среде, которую я желаю. Это плохой дизайн, чтобы позволить объекту знать его представление XML (или представление CSV и т. Д.)? Должно ли знание этой структуры быть сохранено на другом уровне, и на каком уровне это будет?

Answer 1

Не могли бы вы просто поменять свой XML-репозиторий на SQL-сервер? На самом деле не имеет значения, какие репозитории yopur предназначены для того, чтобы быть «черными ящиками» для хранения и извлечения ваших данных. Храните свои секретные знания XML в репозитории XML и просто добавляйте их с помощью SQL.

Вы можете связать его с вашим хранилищем SQL или оставить отдельно.

Answer 2

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

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

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

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

Answer 3

Мне кажется, что процессы convert-object-to-text-format и store-text -where могут и должны быть разделены. Я думаю, что из этого будет «основным», зависит от того, как именно структурировано ваше приложение. То есть будь ты

1. Скажите объекту: «Храни себя», и конфигурация приложения определяет, что это означает формат X и хранилище Y.
2. Скажите объекту: «Сохраните себя в базе данных», и хранилище базы данных запросит объект для его текстового формата (или передаст объект на сервисный уровень, который возвращает этот текст).
3. Скажите объекту "иди храните свой XML", и тогда этот процесс сериализации знает, какой механизм хранения выбрать.

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

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

Answer 4

Если структура XML постоянна, вы можете увидеть мой пост в блоге Easy Xml Serialization . Это позволяет писать XML, но в основном читать его. После того как все ваши классы созданы для вашего XML, вы можете легко получить доступ к своим объектам через код и выполнить пакетный скрипт make / run непосредственно из вашего кода, при этом гарантируя, что данные верны и соблюдают определенную схему.

Конечно, лучше всего по-прежнему делать базу данных CSV> напрямую с некоторым DTO, если это возможно.

Answer 5

Постоянство можно рассматривать как сквозную проблему, означающую, что объекту должно быть все равно, как выполняется постоянство, только что оно должно быть выполнено; Например, вы можете определить PersistentStoreFactory, который создает объекты, которые реализуют интерфейс PersistentStore, который имеет один общий метод Persist.

Затем можно украсить класс с помощью атрибута Persist, который будет использовать фабрику для создания PersistentStore, а затем вызвать метод Persist, передающий экземпляр объекта. Если в будущем вы решили, что вам нужны разные механизмы персистентности для разных типов классов, вы можете расширить свой атрибут, добавив аргумент типа string, чтобы показать PersistanceMedia, т.е. базу данных, файловую систему, облако, URL и т. Д.

Answer 6

Вы также можете попробовать собственную базу данных XML, такую ​​как eXist , которая вполне подойдет для ваших нужд хранения и извлечения XML.

Обновление : другим решением может быть использование возможностей XML вашей СУБД. Почти все современные СУБД поддерживают типы XML, поэтому лучше всего придерживаться этого (используя типы XML для столбцов, в которых вы будете хранить данные).

Обновление 2 : Если вам нужно просто сохранить структурированную информацию (вы импортируете из CSV и сохраняете ее в одном XML-файле, если я не ошибаюсь), почему бы не использовать старую старую RDMBS ? Я не нахожу никаких преимуществ в хранении данных в XML-файле, который может расти без контроля. Что происходит, когда вы хотите получить обратно некоторые данные (суммированные или нет) из этого файла? Чем больше становится, тем больше времени и компьютерных ресурсов потребуется для выполнения работы. Если вы используете SAX, вам потребуется обработать весь файл, поэтому доступ к данным в конце файла займет больше времени, чем доступ к его началу. Использование DOM было бы еще хуже, поскольку чем больше размер файла, тем больше памяти вам нужно для его обработки.

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

Answer 7

Если вы хотите, чтобы репозиторий SQL мог использовать существующий слой xml, то я уверен, что возможна какая-то абстракция на основе интерфейса (provider / IoC / DI / etc), так что репозиторий SQL может потреблять стек xml без необходимости знать об этом явно.

Конечно, если объектная модель сама определила структуру xml (через атрибуты для XmlSerializer и т. Д.), То это проще, и репозиторий xml становится довольно тривиальным.

Что касается знания структуры внутри базы данных: это зависит от того, нужно ли вам запрашивать данные внутри базы данных. Если это так, вы можете многое сделать в SQL Server - например, вы можете привязать столбец xml к xsd, или вы можете рекламировать части xml (через udf / xquery) в постоянные индексированные столбцы. Однако, если вы просто используете базу данных для хранения, тогда это не является необходимым - и действительно, использование xsd в базе данных является основной PITA, если вам нужно изменить xsd позднее (это не тривиально).