如何以编程方式在本地网络上发现数据库

时间:2012-04-23 12:35:24

标签: java database-connection

我正在开发一个需要自定义“向导”的项目,以帮助非技术用户安装自定义数据库驱动的应用程序。主要问题是如果已经有适当的数据库引擎,则不为自定义应用程序设置新数据库。所以问题来了:如何以编程方式检测现有数据库引擎的类型和位置?

这里的技巧是安装程序的要求是向导协助非技术用户决定兼容性列表中的本地专用网络上是否存在数据库引擎。如果是这样,请协助非技术用户与所选数据库引擎建立连接。否则,向导将安装数据库等。

不管现有数据库场景如何,安装首选DBMS会更好吗?该平台是一个Windows框,但平台独立性是该项目的目标。

我不知道我是否只是使用了错误的搜索词,或者是否真的没有这方面的信息,但是发现这是否可能是令人沮丧的。

非常感谢任何帮助,建议,链接,代码资源等。

编辑检测现有数据库的位置和类型的目的是提供一个用户可以选择的简单列表,以便在专用网络上添加应用程序的其他实例对于当前版本或作为版本的升级(以实现“干净”安装)。应用程序有点分布,因为通常会有许多应用程序实例(3-10)作为终端与数据库交互,以不同方式操纵信息以用于不同终端上的不同用途。我认为首选的DBMS已经确定了PostgreSQL。

  • 史蒂夫

2 个答案:

答案 0 :(得分:2)

如果您知道要尝试连接的数据库类型,则应该能够ping该类型数据库的默认端口,以查看它是否返回响应。或者,尝试打开与数据库的实际连接,看看是否收到回复。

变得更复杂,如果您可以访问网络上的PC,请浏览到数据库类型的默认安装目录以查看是否存在任何内容。

到目前为止,这两个要求使用默认位置和端口安装数据库。

变得更复杂,如果您可以连接到删除PC上的注册表,那么您可以在注册表树中找到数据库 - 无论用户在何处安装数据库,这都将得到修复


我的建议可能是完全避免这种情况,因为它增加了很多复杂性而没有太多的回报。如果您的应用程序是针对非技术最终用户的,那么最好只假设没有可用的数据库,只需在安装程序中安装一个新数据库即可。如果您向非技术用户提供一整套对他们没有任何意义的数据库选项,他们就会感到困惑。

查询本地网络可能还需要很长时间,具体取决于存在的网络共享数量以及响应速度。所有这些都会影响安装程序的响应能力,因此最终用户可能不知道安装程序没有做任何事情的原因。

如果你真的想要选择一个现有的数据库,我会把它作为一个单独的可选按钮,将它们带到另一个屏幕,在那里他们可以选择一个网络主机进行调查 - 唯一可以访问的人这个屏幕可能是更技术性的人,他们可能知道数据库在哪里存在。

答案 1 :(得分:1)

  

如果已经有适当的数据库引擎,主要关注的是不为自定义应用程序设置新数据库。

我不太明白向导如何确定现有数据库是否合适。假设它在网络上找到3个Oracle和4个MySQL实例 - 它将如何选择?而且,这种方法在用户的应用程序和网络上的另一台机器之间产生依赖性,而用户甚至不知道它。当数据库明天不可用时,用户会做什么?

在我看来,如果数据需要在多个用户或多个系统之间共享,那么数据库的选择必须是用户明确,有意识的操作。另一方面,如果数据库只是应用程序存储某些内容的地方,那么它应该安装一个 - 最好是轻量级的,如HSQLDBSQLite