通过PHP将图像上传到SVN并将元数据存储在多个数据库中

我们目前正在设计重写我们的PHP网站。新版本将受SVN版本控制，并有一个单独的数据库用于开发和现场站点

目前我们在网站上有大约200000张图片，我们每月增加5-10张。我们希望在SVN下也有这些图像

当前的计划是存储和服务文件系统中的图像，同时从数据库中服务它们的元数据。图像将通过具有Apache重写规则的PHP图像系统提供，以便访问PHP脚本，该脚本查询数据库中具有指定ID的图像，并（基于表中的

路径
列）返回相应的图像

我面临的问题是如何在实时和开发站点之间保持图像文件及其元数据的同步

添加新图像对开发团队来说（虽然笨拙，但）很容易：我们可以将图像添加到我们的SVN存储库中，方法与在实时和测试数据库中手动创建元数据的方式相同

当我们的员工需要通过网站上传新图片时，问题就出现了

我能想出的一个可行的解决方案是让我们的PHP上传脚本将新图像提交给SVN，并向live和development数据库发送INSERT查询。但对我来说，这似乎效率低下。另外，PHP中的SVN支持仍然是实验性的，我不喜欢依赖exec（）调用

我还考虑了第三个单独的数据库，只用于图像元数据。以及不在SVN中存储图像（但它们是应用程序的一部分，而不仅仅是“内容”图像，最好只是备份）

我真的很想在SVN中保存图像，如果我这样做了，我需要它们与实时和开发站点之间的元数据保持一致。我还必须为用户上传的图像提供一种机制

处理这种情况的最佳方法是什么？
我已经为许多不同的环境解决了这类问题。以下是我使用过的一些技巧；一些组合可以解决你的问题，或者至少给你正确的洞察力来解决你的问题

开发期间控制应用程序数据的版本
我在一个数据库应用程序上工作，该应用程序需要能够作为应用程序的一部分交付某些数据。当我们交付新版本的应用程序时，数据库模式可能会发生变化，因此我们需要SQL脚本（1）从头创建所有应用程序表，或（2）更新所有现有表以匹配新模式，添加新表，并删除不需要的表。此外，我们需要能够证明，无论升级哪个版本的应用程序，升级脚本都能工作（我们无法控制部署环境或升级计划，因此给定站点可能需要从1.1升级到1.3，跳过1.2）

在本例中，我所做的是使用一个工具，将数据库转储为一个包含所有表定义和数据的大型SQL脚本。然后，我编写了一个工具，将这个巨大的脚本拆分为每个表、存储过程、函数等的单独文件（片段）。我还编写了另一个工具，它将获取所有片段并生成一个SQL脚本。最后，我编写了在安装期间使用的第三个工具，该工具将根据数据库和已安装应用程序的状态确定在安装期间运行哪些脚本。一旦我对这些工具感到满意，我就在当前数据库上运行它们，然后编辑片段以消除无关数据，只留下我们想要运送的部分。然后，我对这些片段进行版本控制，以及一组表示字段中数据库的数据库转储

我对数据库的回归测试将涉及恢复数据库转储，运行安装程序升级数据库，转储结果并将转储拆分为片段，然后将片段与提交的版本进行比较。如果存在任何差异，则表明升级或安装片段中存在问题

在开发过程中，开发人员将运行安装工具来初始化（真正升级）他们的开发数据库，然后进行更改。他们将运行dump/split工具，提交更改的片段，以及一个升级脚本，该脚本将升级任何现有表以匹配新模式。持续集成服务器将检查更改、构建所有内容并运行所有单元测试（包括我的数据库回归测试），然后将矛头指向忘记提交所有数据库更改的开发人员（或相应的升级脚本）

将实时数据迁移到测试站点
我使用Wordpress（在PHP和MySQL上）建立网站，我需要保持每个网站的“实时”和“测试”版本。特别是，我经常需要将所有数据从“实时”拉到“测试”中，以便查看实时数据的某些变化。本例中的数据是网页、上传的图像和图像元数据，图像元数据存储在MySQL中。每个站点都有完全独立的文件和数据库

我制定的方法是一组脚本，可执行以下操作：

从配置数据中提取两组（源和目标）数据库凭据和文件位置
为源网站添加有问题的文件
清除目标网站的文件区域
将文件解压到目标文件区域
将源数据库的相关表转储到文件中
从目标数据库中的匹配表中删除所有数据
从转储文件加载表数据
运行SQL查询以修复与目标文件匹配的任何源路径名