默认情况下,析构函数不是虚拟的,在不需要它时不会受到伤害,这很好.
但是在基类派生类场景的情况下,是否有任何用例没有虚拟析构函数？如果没有可能(有意义的话),如果一个类派生自一个定义了公共非虚拟析构函数(或没有析构函数)的基类,编译器就会抱怨.而不只是警告它.
我特别感兴趣的场景是具有在某些配置参数上运行的守护进程的多个服务器.(因为,这是一个学习练习.我欢迎任何超出这个特殊情况的想法)问题是,配置参数应该放在哪里.
A.中央数据库表
B.将配置文件推送到每个框
这些是我遇到的最常见的.值得注意的是,在代码常量中(需要重新编译才能部署.除非它们确实是常量,所以选项不好),配置文件安装在共享位置.
只是想从社区了解你如何做出选择.
让我们先写一些数字:列表中最大的是大约100M的记录.(但预计会增长到500).其他列表(其中5-6个)以百万计,但在可预见的未来将小于100M.这些总是基于单个id加入.并且从不与任何其他参数.什么是加入此类列表的最佳算法？
我正在考虑分布式计算.有一个很好的哈希(循环哈希种类,你可以添加一个节点,并没有很多数据移动)功能,并将这些列表拆分成几个较小的文件.因为,他们总是加入共同的id(我将要哈希),它将归结为加入小文件.也许可以使用nix join命令.
DB(至少MySQL)将使用合并连接加入(因为它将在主键上).这会比我的方法更有效吗？
我知道最好测试一下.但考虑到这些文件的大量,它非常耗时.我想做一些理论计算,然后看看它在实践中是如何展开的.
对这些或其他想法的任何见解都会有所帮助.我不介意它需要稍微长一点,但更喜欢我拥有的资源的最佳利用.没有庞大的预算:)