Универсальный формат резервного копирования / извлечения базы данных

существует ли универсальный формат резервного копирования / извлечения базы данных?

Я объясню, откуда я пришел: наше приложение поддерживает несколько поставщиков баз данных, DB2, MsSql, MySql и Oracle. В настоящее время, когда мы запрашиваем резервную копию у клиента, он должен сделать полную резервную копию в формате, специфичном для поставщика.

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

Решение состоит в том, чтобы использовать существующий стандартный отраслевой формат резервного копирования / извлечения, если он существует. Хотя я не против изобрести свой собственный формат, у отраслевого стандартного формата было бы больше возможностей.

Он существует или мне придется его изобрести?

Заранее спасибо,

Стивен.


database backup extract
person Steve    schedule 07.10.2009    source источник

Ответы (5)


arrow_upward
0
arrow_downward

Единственный универсальный формат экспорта - это какая-то вариация на тему текстового дампа.

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

Еще одна сложная часть - это то, как разные СУБД предпочитают кодировать такие вещи, как значения BLOB двоичных данных - Base64, шестнадцатеричный, ... и, возможно, некоторые другие ...

XML также возможен, но не существует стандартизации того, какую схему XML или DTD использовать.

person Jonathan Leffler    schedule 07.10.2009
comment
Я понимаю трудности с нестандартными типами полей. К счастью, на данный момент мы используем только общее подмножество. XML может показаться идеальным выбором, если вы не считаете, что некоторые базы данных превышают 20 ГБ. XML добавил бы много накладных расходов, если бы не использовалось сжатие, и тогда событие ....? - person Steve; 07.10.2009

arrow_upward
1
arrow_downward

К вашему сведению: в конце концов я решил использовать SQLite в качестве нашего формата. На это есть несколько причин:

  1. Использует один файл, который очень удобен для транспортировки.
  2. Поддерживает все необходимые нам типы полей.
  3. Имеет поддержку многих платформ и языков.
  4. Имеет открытый исходный код и бесплатен.
  5. Маленький след.
  6. Очень быстро для добавления записей.
  7. Наши приложения могут напрямую взаимодействовать с базами данных SQLite.

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

person Steve    schedule 22.09.2012

arrow_upward
0
arrow_downward

Как насчет XML? CSV?

person Jay Riggs    schedule 07.10.2009
comment
В этом случае мне нужно будет определиться с форматом, поэтому я считаю, что это доморощенный формат. Также, как показано ниже, насчет сжатия. - person Steve; 07.10.2009
comment
@Steve: Вы спрашивали об отраслевых стандартах для этого. Это XML и CSV. - person Ben S; 08.10.2009
comment
Это примерно так, как я понял. Таким образом, хотя XML и CSV являются отраслевыми стандартами, нет отраслевого стандарта, описывающего, как вы можете хранить в них полную резервную копию базы данных. Если бы я использовал XML, мне пришлось бы решать, как организовать данные в XML-файле, а не стандартным способом. Мне бы очень хотелось, чтобы у меня был файл резервной копии (backup.xyz), который я могу импортировать / восстанавливать в любую базу данных аналогично тому, как MsSQl может восстанавливать файл .bak. - person Steve; 09.10.2009

arrow_upward
0
arrow_downward

Все известные мне СУБД (включая все перечисленные вами) поддерживают экспорт и импорт в CSV.

Чтобы получить бонусные баллы, сожмите экспорт для экономии места.

person Ben S    schedule 07.10.2009
comment
Сжатие определенно необходимо, хотя бы для того, чтобы иметь возможность. - person Steve; 07.10.2009

arrow_upward
0
arrow_downward

Думаю, нужно искать инструмент, способный перекачивать данные.

Вот один пример: http://www.clevercomponents.com/products/datapump/ibdatapump.asp

Это не будет соответствовать вашим потребностям, но, возможно, это то, что вам нужно.

person Hugues Van Landeghem    schedule 07.10.2009
comment
Я загрузил его и попытался запустить, но, к сожалению, он не работает без установленной Interbase. Однако может показаться, что IBPump копирует данные непосредственно из источника в место назначения, не проходя через промежуточный формат. Нам понадобится промежуточный формат, поскольку исходная и целевая базы данных редко находятся в одной сети. Иногда клиентские базы данных настолько велики, что требуется внешний жесткий диск и курьер, поскольку передача через Интернет может занять слишком много времени. - person Steve; 08.10.2009