I have a Java application that uses an Apache Derby database with the embedded driver. Right now, in the installation, I run the SQL create scripts out of process.
我有一个Java应用程序，它使用嵌入式驱动程序使用Apache Derby数据库。现在，在安装过程中，我在进程外运行SQL create脚本。
So when the application starts up, the tables are already existing. Recently I've started to think it would be better to have my SQL script in the classpath or something, load it, and execute all the statements so that the tables are created upon startup. The database itself can be autocreated if missing, so this seems like it might be a less error-prone way to bootstrap the tables.
因此，当应用程序启动时，表已经存在。最近我开始认为，最好将SQL脚本放在类路径中，加载它，并执行所有语句，以便在启动时创建表。如果数据库本身丢失，可以自动创建，因此这似乎是一种引导表的更少出错的方法。
My question is: Am I likely to run into any issues with detecting existence/creating tables in process on application startup vs. expecting them to be set up properly by my install?
我的问题是:在应用程序启动时检测存在/创建表是否会遇到任何问题，还是希望通过我的安装正确地设置它们?
3 个解决方案
#1
1
I think your first step should be to build them during the install and fail gracefully at runtime. Then flesh out the fail gracefully part to be self-repairing.
我认为您的第一步应该是在安装期间构建它们，然后在运行时优雅地失败。然后温文尔雅地充实失败的部分自我修复。
Detecting and handling error conditions in process is, IMO, always better than assuming (expecting) and crashing.
在我看来，检测和处理过程中的错误情况总是比假设(预期)和崩溃要好。
I would advocate not "expecting" tables to be set up properly by the install. I'm not saying you shouldn't set the database up during the install. What I'm advocating for is code that verifies database integrity. If you have code that verifies the existence and design of your schema and can repair/rebuild, then you don't need to worry about whether the install set everything up properly. This doesn't mean you shouldn't do that creation during the install, especially if it's slow.
我主张不要“期望”通过安装正确地设置表。我不是说在安装过程中不应该设置数据库。我所提倡的是验证数据库完整性的代码。如果您有代码来验证模式的存在和设计，并且可以修复/重建，那么您就不需要担心安装是否正确地设置了一切。这并不意味着您不应该在安装过程中进行该创建，特别是如果它很慢的话。
I know that a lot of the apps I develop these days have built in migrations based on app version. Basically, when the app starts up it goes through a DB validation/verification cycle, determines the state of the database, and performs associated migrations based on database version and code version.
我知道我最近开发的很多应用都是基于app版本进行移植的。基本上，当应用程序启动时，它会经过DB验证/验证周期，确定数据库的状态，并基于数据库版本和代码版本执行相关的迁移。
This requires you to be diligent with up and down migrations (or just up, if you never need to rev back) but I've found it to be a very slick and useful solution. Of course, you need it to be robust against multiple startups, user configuration differences, and be able to handle error situations gracefully, but that's par for the course, in my opinion.
这就要求你在上下迁移时要勤奋(或者如果你永远不需要重新启动的话，就只需要向上)，但我发现这是一个非常灵活和有用的解决方案。当然，您需要它对多个初创公司、用户配置差异具有健壮性，并且能够优雅地处理错误情况，但在我看来，这是正常的。
#2
0
I would depend on them occurring during the install. If you create them automatically during startup, you have to worry about multiple concurrent startups, a situation which is much less likely to occur during installation (and which your installer framework probably handles already).
我将依赖于它们在安装过程中出现。如果您在启动时自动创建它们，您必须担心多个并发启动，这种情况在安装期间发生的可能性要小得多(安装程序框架可能已经处理了这种情况)。
#3
0
I think that it is a bad idea to decide for the user what's best for him. Imagine that the application is started up accidentally on an incorrect database. Do you really want the application to create the tables on this incorrect database?
我认为这是一个坏主意，为用户决定什么是最好的他。假设应用程序是在不正确的数据库上意外启动的。您真的希望应用程序在这个不正确的数据库上创建表吗?
Instead, warn the user that the database tables were not found, and offer him an option to create them, e.g. by telling him that he should start the application with a specific command line option (e.g. /CREATETABLES) of by showing him a dialog in which he can choose to create the tables.
相反,警告用户数据库表没有发现,并提供一个选项来创建它们,例如,告诉他,他应该与一个特定的命令行选项启动应用程序(例如/不知道)的显示一个对话框中,他可以选择创建表。
Things might become more complex if the user must not create the tables, but another responsible (an administrator, a key user) should create them. In that case, you could just give an error code and point the user to this responsible.
如果用户必须不创建表，那么事情可能会变得更复杂，但是另一个负责人(管理员、关键用户)应该创建它们。在这种情况下，您只需提供一个错误代码，并将用户指向该负责人。
#1
1
I think your first step should be to build them during the install and fail gracefully at runtime. Then flesh out the fail gracefully part to be self-repairing.
我认为您的第一步应该是在安装期间构建它们，然后在运行时优雅地失败。然后温文尔雅地充实失败的部分自我修复。
Detecting and handling error conditions in process is, IMO, always better than assuming (expecting) and crashing.
在我看来，检测和处理过程中的错误情况总是比假设(预期)和崩溃要好。
I would advocate not "expecting" tables to be set up properly by the install. I'm not saying you shouldn't set the database up during the install. What I'm advocating for is code that verifies database integrity. If you have code that verifies the existence and design of your schema and can repair/rebuild, then you don't need to worry about whether the install set everything up properly. This doesn't mean you shouldn't do that creation during the install, especially if it's slow.
我主张不要“期望”通过安装正确地设置表。我不是说在安装过程中不应该设置数据库。我所提倡的是验证数据库完整性的代码。如果您有代码来验证模式的存在和设计，并且可以修复/重建，那么您就不需要担心安装是否正确地设置了一切。这并不意味着您不应该在安装过程中进行该创建，特别是如果它很慢的话。
I know that a lot of the apps I develop these days have built in migrations based on app version. Basically, when the app starts up it goes through a DB validation/verification cycle, determines the state of the database, and performs associated migrations based on database version and code version.
我知道我最近开发的很多应用都是基于app版本进行移植的。基本上，当应用程序启动时，它会经过DB验证/验证周期，确定数据库的状态，并基于数据库版本和代码版本执行相关的迁移。
This requires you to be diligent with up and down migrations (or just up, if you never need to rev back) but I've found it to be a very slick and useful solution. Of course, you need it to be robust against multiple startups, user configuration differences, and be able to handle error situations gracefully, but that's par for the course, in my opinion.
这就要求你在上下迁移时要勤奋(或者如果你永远不需要重新启动的话，就只需要向上)，但我发现这是一个非常灵活和有用的解决方案。当然，您需要它对多个初创公司、用户配置差异具有健壮性，并且能够优雅地处理错误情况，但在我看来，这是正常的。
#2
0
I would depend on them occurring during the install. If you create them automatically during startup, you have to worry about multiple concurrent startups, a situation which is much less likely to occur during installation (and which your installer framework probably handles already).
我将依赖于它们在安装过程中出现。如果您在启动时自动创建它们，您必须担心多个并发启动，这种情况在安装期间发生的可能性要小得多(安装程序框架可能已经处理了这种情况)。
#3
0
I think that it is a bad idea to decide for the user what's best for him. Imagine that the application is started up accidentally on an incorrect database. Do you really want the application to create the tables on this incorrect database?
我认为这是一个坏主意，为用户决定什么是最好的他。假设应用程序是在不正确的数据库上意外启动的。您真的希望应用程序在这个不正确的数据库上创建表吗?
Instead, warn the user that the database tables were not found, and offer him an option to create them, e.g. by telling him that he should start the application with a specific command line option (e.g. /CREATETABLES) of by showing him a dialog in which he can choose to create the tables.
相反,警告用户数据库表没有发现,并提供一个选项来创建它们,例如,告诉他,他应该与一个特定的命令行选项启动应用程序(例如/不知道)的显示一个对话框中,他可以选择创建表。
Things might become more complex if the user must not create the tables, but another responsible (an administrator, a key user) should create them. In that case, you could just give an error code and point the user to this responsible.
如果用户必须不创建表，那么事情可能会变得更复杂，但是另一个负责人(管理员、关键用户)应该创建它们。在这种情况下，您只需提供一个错误代码，并将用户指向该负责人。