|
锁定老帖子 主题：如何让系统支持多种数据库
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-14
为什么不是支持postgreSQL和oracle的呢？他们是可以兼容的。
|
| 返回顶楼 | |
|
发表时间：2012-02-14
kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 扩展不是万能的，既然支持多数据库，本来就要维护那些不同特性的部分，只是把这些不同的地方尽可能降低到最少。 |
| 返回顶楼 | |
|
发表时间：2012-02-14
尽量使用标准的SQL语法，要不用HSQL，要不好像无他法
|
| 返回顶楼 | |
|
发表时间：2012-02-15
AndyTse 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 扩展不是万能的，既然支持多数据库，本来就要维护那些不同特性的部分，只是把这些不同的地方尽可能降低到最少。 我想表达的意思是，程序也不是万能的，这种就应该由其他途径解决，比如销售，想办法让客户不要提这种需求，有几个项目是会中途换数据库的？ |
| 返回顶楼 | |
|
发表时间：2012-02-15
kanme818 写道 AndyTse 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 扩展不是万能的，既然支持多数据库，本来就要维护那些不同特性的部分，只是把这些不同的地方尽可能降低到最少。 我想表达的意思是，程序也不是万能的，这种就应该由其他途径解决，比如销售，想办法让客户不要提这种需求，有几个项目是会中途换数据库的？ 不一定是中途换数据库，也是在谈另外一个客户的时候，对方因为自己企业的问题，只能选择某一个数据库。 |
| 返回顶楼 | |
|
发表时间：2012-02-15
kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 呵呵 需求变肯定需要改程序了，，，但是我们设计开发的宗旨是当有新的需求以及原有需求改变的时候，我们可以做到以最少的修改或者最方便的扩展来满足客户的需求。 这个功能本来就是可以实现的，为什么要去劝客户不这么做，，呵呵，，会让客户想 你们公司是不是技术不行啊，这不做那不做的，那我换家公司做吧。 |
| 返回顶楼 | |
|
发表时间：2012-02-15
a1721615168 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 呵呵 需求变肯定需要改程序了，，，但是我们设计开发的宗旨是当有新的需求以及原有需求改变的时候，我们可以做到以最少的修改或者最方便的扩展来满足客户的需求。 这个功能本来就是可以实现的，为什么要去劝客户不这么做，，呵呵，，会让客户想 你们公司是不是技术不行啊，这不做那不做的，那我换家公司做吧。 没见过中途变数据库的项目，客户可能也不懂，你就应该帮他阐明清楚，哪些是重要的，哪些是次要的，不是人家提了什么需求都要接受。 |
| 返回顶楼 | |
|
发表时间：2012-02-15
AndyTse 写道 kanme818 写道 AndyTse 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 扩展不是万能的，既然支持多数据库，本来就要维护那些不同特性的部分，只是把这些不同的地方尽可能降低到最少。 我想表达的意思是，程序也不是万能的，这种就应该由其他途径解决，比如销售，想办法让客户不要提这种需求，有几个项目是会中途换数据库的？ 不一定是中途换数据库，也是在谈另外一个客户的时候，对方因为自己企业的问题，只能选择某一个数据库。 能牵涉到特定数据库特有特性的时候，这项目应该已经很深入了吧，这时候还没决定用哪个数据库？ |
| 返回顶楼 | |
|
发表时间：2012-02-15
kanme818 写道 AndyTse 写道 kanme818 写道 AndyTse 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 扩展不是万能的，既然支持多数据库，本来就要维护那些不同特性的部分，只是把这些不同的地方尽可能降低到最少。 我想表达的意思是，程序也不是万能的，这种就应该由其他途径解决，比如销售，想办法让客户不要提这种需求，有几个项目是会中途换数据库的？ 不一定是中途换数据库，也是在谈另外一个客户的时候，对方因为自己企业的问题，只能选择某一个数据库。 能牵涉到特定数据库特有特性的时候，这项目应该已经很深入了吧，这时候还没决定用哪个数据库？ 比如贵公司给a公司做了一套系统，但b公司也对这套系统感兴趣，业务需求差不多，但2公司数据库系统因为企业自身原因，一个需要sql server，一个需要oracle，这种事情不是很有可能么。 |
| 返回顶楼 | |
|
发表时间：2012-02-15
kanme818 写道 a1721615168 写道 kanme818 写道 a1721615168 写道 caizi12 写道 WAMING5 写道 用抽象工厂设计不同的数据库DAO,根据数据库配置选择不同DAO实例
你这样设计和做四个支持不同数据库的系统有多大区别。 哈哈 有意思 像你这种想法 那还要设计模式干嘛 有什么用 需要改的时候我在重写一套不就完了 但是你要知道，好的程序，健壮的程序，容易扩展的程序是需要遵循开发规则的， 首先使用抽象工厂实现 只需要提供不同的实现DAO层就行 每种数据库的DAO都分别实现一个 他遵守了开放封闭原则，有需求变更的时候不需要修改代码但是可以新加类来扩展，如果以后还需要增加sqlserver的支持 我只需要在新建一个sqlserver 的实现DAO 降低了代码的耦合度 就OK了 其他的都不需要变 你说方便不方便 在一个 如果你使用了抽象工程 你就可以配置你的 oracleDaoService 是单例模式 还是 原型模式 极大的可配置性，同时还可以提高程序的性能 多好啊！ 想加什么就加什么，想怎么改就怎么改 你说的那个实现4个系统 那一改 得乱成啥样，我改一个地四个产品都得改，一想都脑袋疼，还是个产品 老的程序员走了 在招新的程序员去改 那新的程序员估计想死的心都有了。 那如果现在业务有所改变，需要改一下SQL逻辑，那你要改几次SQL？技术带来的好处都知道，有谁想过带来好处的同时也会伴随副作用。 呵呵 需求变肯定需要改程序了，，，但是我们设计开发的宗旨是当有新的需求以及原有需求改变的时候，我们可以做到以最少的修改或者最方便的扩展来满足客户的需求。 这个功能本来就是可以实现的，为什么要去劝客户不这么做，，呵呵，，会让客户想 你们公司是不是技术不行啊，这不做那不做的，那我换家公司做吧。 没见过中途变数据库的项目，客户可能也不懂，你就应该帮他阐明清楚，哪些是重要的，哪些是次要的，不是人家提了什么需求都要接受。 现实中是有这种情况的 很正常，，比如说 一家公司想买我们公司的产品，，，那买我们公司的产品的是消费者，，，我们公司是生产者，，，下面我就直接说生产者和消费者了，，， 比如说消费者想买生产者的产品，，，但是消费者公司只有一台非常牛的oracle服务器，而且他们公司包括oa或者其他的项目的数据库也都是oracle,,,那他们新上的项目 新买的产品也希望是oracle的 方便管理，不想在去购买其他的数据库服务器了。而且他们的数据库管理员也只会oracle数据库管理。 那生产者的项目只支持mysql的 ，这就不行了吧。。 |
| 返回顶楼 | |
