Как хранить и развертывать порции реляционных данных?

Question

У меня есть Postgres DB, содержащая некоторые данные конфигурации, распределенные по нескольким таблицам.Эти конфигурации необходимо протестировать перед их развертыванием в производственной системе.Сейчас я ищу способ

1. хранить отдельные объекты конфигурации с их дочерними объектами в SVN и
2. для развертывания этих объектов с дочерними объектами в разных целевых БД

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

Например, если база данных будет содержатьданные о музыкальных исполнителях, альбомах и дорожках с простой схемой в виде древовидной таблицы, например, исполнитель -> имеет альбомы -> имеют дорожки, то решение, которое я ищу, позволит экспортировать, например, один выбранный альбом со всеми дорожками (или одного исполнителя со всемиальбомы со всеми дорожками) в один файл, который можно сохранить в SVN, а затем «развернуть» в любой БД, имеющей ту же схему.

Я думал о том, чтобы реализовать что-то сам, например, иметь файл конфигурации, описывающий зависимостии скрипт экспорта, который заменяет идентификаторы переменными PHP и генерируеткакой-то PHP-SQL INSERT или UPDATE скрипт.Но потом я подумал, что было бы очень глупо не спрашивать, прежде чем перепроверить, если что-то подобное уже существует: o)

Answer 1

Это один из аргументов в пользу Natural Keys. Альбом имеет исполнителя и состоит из треков. Не нужно идентификатора, чтобы связать эти фрагменты информации, просто используйте имена. Perl-esque пример файла данных:

"Bob Artist" => {
    "First Album" => ["My Best Song", "A Slow Song",],
    "Comeback Album" => ["One-Hit Wonder", "ORM Blues",],
}, "Noname Singer" => {
    "Parse This Record!" => ["Song Named 'D'",],
}

Чтобы добавить данные, достаточно просто пройтись по дереву, создавая операторы INSERT, основанные на каждом уровне родительских данных, и, если они у вас должны быть, использовать «RETURNING id» (расширение PostgreSQL) в конце каждого оператора INSERT, чтобы получить авто- сгенерированные идентификаторы для перехода на следующий уровень вниз по дереву.

Answer 2

Концепция миграции Rails представляется актуальной, хотя она нацелена главным образом на выполнение обновлений схемы: http://guides.rubyonrails.org/migrations.html

Идея перенесена в PHP с именем Ruckusing , но, похоже, на данный момент поддерживает только mySQL: http://code.google.com/p/ruckusing/wiki/BigPictureOverview

Doctrine также предоставляет функциональные возможности миграции, но, похоже, снова сосредоточен на преобразованиях схемы, а не на миграции или развертывании данных: http://www.doctrine -project.org / projects / migrations / 2.0 / docs / en

Возможно, Ruckusing или Doctrine могут быть использованы (злоупотреблены?) Или, если необходимо, изменены / расширены для выполнения работы?

Answer 3

Я второе предложение Мэтью.В качестве уточнения этой концепции вы можете создать «производные естественные ключи», например «bob_artist» для «Bob Artist».Производный естественный ключ хорошо подходит, например, в качестве имени файла при сохранении записи в svn.

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