拥有一个巨大的database serialization class或many classes each for one storable class更好吗？
我想编写我的教育数据库应用程序。但是在开始之前，我想编写一个不错的数据库序列化和更新系统。
该系统将使我遵循良好的建议：DRY（请勿重复）。在这种情况下，我不想在C ++中重新实现对象定义，而在SQL中重新实现对象定义。
为此，我将使用哑定义扩展一些C ++类声明：
PRIMARY_KEY, FOREIGN_KEY(class.variable1, class.variableN), INDEX, NO_STORE).
这个定义只对我的类定义解析器有影响。该解析器是SQL结构生成器和SQL升级补丁的输入。唯一不能自动解决的问题是migrationData（）函数（生成该函数是为了避免错误地破坏数据库而将其断开）。
这使我能够使用自动补丁程序对数据库结构进行全自动跟踪。
事实上，我已经做到了。
我有这样的类层次结构： 数据库1 <-数据库2 <-数据库N 每个DatabaseX都具有update（）和migration（）函数。
然后我有类似的东西：
using Db = DatabaseN;
class DbMyApp : public Db
{
// Specific app db/SQL calls here (covered by C++ functions)
};
这使我可以在应用程序中使用最后生成的数据库（无需任何全局重命名或类似的操作）-这可以使代码中所需的更改最小化。
所以我有一个巨大的DatabaseN类（又称Db），它可以序列化和反序列化应用程序中所有可存储的类。
但是在我的新作品中，我发现有些事情与我的做法有所不同。他们实现了序列化抽象类，并且为每个可存储类实现了单独的序列化类。
我的问题是： 哪种方法更好？又为什么呢？一个全局序列化类，或者每个可存储类一个序列化类？
我觉得我的实现更好，因为我只关心一个巨大的Database类，我对许多“ using”或“ typedef”子句没有任何疑问，我不记得我的序列化类是如何命名的，许多都不需要。因此，在一个大的生成类中很方便。
不好的地方是：测试数据库类生成器和Sql补丁生成器在这两种方法中都是噩梦。因为您必须编写要测试哪个程序才能生成程序的程序。但是我曾经很自豪地做到了。但是我希望它下次能够变得更好（以Qt独立的方式，因为将来我想完全删除此lib）。