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

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

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

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

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

Существует ли один, или я должен его изобрести?

Заранее благодарен,

Stephen.

источник

2009-10-07 Steve

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

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

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

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

источник

2009-10-07 18:46:15

Я понимаю трудности с нестандартными типами полей. К счастью, на данный момент мы используем только одно подмножество. XML представляется идеальным выбором, пока вы не подумаете, что некоторые из баз данных превышают 20 Гб. XML добавит много накладных расходов, если не будет использовано сжатие и событие ...? – Steve

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

источник

2009-10-07 18:34:48

В этом случае мне нужно будет принять решение о формате, поэтому я бы подумал, что это доморощенный формат. Кроме того, как показано ниже, что касается сжатия. – Steve

@Steve: Вы спросили об отраслевых стандартах для этого. Это XML и CSV. –

Thats в значительной степени, как я понял. Таким образом, хотя XML и CSV являются отраслевыми стандартами, нет отраслевого стандарта для описания того, как вы можете хранить в нем полную резервную копию базы данных. Если бы я использовал XML, мне пришлось бы решить, как организовать данные в XML-файле, а не стандартным образом. Мне бы очень понравилась ситуация, когда у меня есть файл резервной копии (backup.xyz), который я могу импортировать/восстанавливать в любую базу данных так же, как MsSQl может восстановить .bak-файл. – Steve

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

Для бонусных очков compress экспорт для экономии места.

источник

2009-10-07 18:36:29

Сжатие, безусловно, обязательно, если только есть опция. – Steve

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

Одним из примеров здесь: http://www.clevercomponents.com/products/datapump/ibdatapump.asp

Он не будет специально соответствовать вашим потребностям, но может быть, это путь.

источник

2009-10-07 21:46:57

Я загрузил его и попытался запустить его, но, к сожалению, он не запускается без установки Interbase. Однако, похоже, что IBPump копирует данные непосредственно из источника в пункт назначения без прохождения через промежуточный формат. Нам нужен промежуточный формат, так как редко, исходная и целевая базы данных находятся в одной сети. Иногда базы данных клиентов настолько велики, что требуется внешний HD и курьер, поскольку передача через Интернет займет слишком много времени. – Steve

FYI: В конце концов, я решил использовать SQLite в качестве нашего формата. У нас есть несколько причин для этого:

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

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

источник

2012-09-22 14:33:08 Steve

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

ответ

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