java图形化界面如何通过编号查询数据库中选手信息

说实话，我在使用Java图形界面查询数据库时遇到了很多错误。
以我们公司当时搭建的运动员管理系统为例。
具体的操作过程确实和你描述的类似，但是有很多细节需要特别注意。

例如，第一步建立连接； JDBC是自带的，但是用起来非常好用，但是用了很久之后。
你会发现每次都要写连接线和驱动加载代码，非常烦人。
后来，我们切换到DBCP数据源。
在启动程序之前初始化一次就足够了。
使用时，直接提取使用。
节省大量工作。
当时经过测试，发现使用连接池比一次重新创建一个连接至少快两到三倍，即使只是一个中型数据库。

第二步是创建查询窗口。
这里最可能的问题是组件布局。
我见过很多新手使用鱼罐头之类的组件进行编码，但当太多用户发现无法使用它们时。
在我们当时的系统中，运动员号码输入框必须经过验证，不能包含字母或特殊符号；否则 SQL 将失败。
后来，又增加了一些实时验证功能。
当用户输入一个字符时；将会评估一次。
当你犯错时，比等到输入完成才报错要好得多，输入字段的边框会变成红色。

第三步是编写SQL。
这是绝对必要的。
当时，一名实习生写了一条查询语句，直接提取了用户输入的数字。
结果有人故意输入“1 OR 1 =1 ”，搞乱了整个系统查询。
后来，我们被迫使用PreparedStatement，参数化查询的好处在当时是非常深刻的。
有一个具体的数据点：系统上线第一周；由于该拼接SQL漏洞，已被黑客攻击3 次。
虽然数据库没有受到直接攻击，但所有记录都被炸毁了。
后来加了防注入模块后，就慢慢好起来了。

第四步，运行结果显示。
这里有一个特别有用的小技巧。
一次整个结果集不要透露它。
会卡住，尤其是数据量很大的时候。
当时我们使用分页查询，用户点击“下一页”去数据库获取新数据。
在实验过程中，我记得使用分页模拟了1 000段运动员数据，一次只能获取2 0段，响应时间稳定在1 秒以下。
如果你一次点所有的东西，加载会很慢，经理会骂你。

但是现在使用 Spring Boot 的 JPA 我们不必担心其中的许多细节。
我们只要写一个方法，数据库的操作基本上都是自动完成的。
这样可以缓解焦虑，但仍然需要了解原理；否则，当你遇到问题时，你会感到困惑。
例如，我们最近升级到 Spring Data JPA 2 .6 使用Querydsl扩展后；自动生成的查询语句比以往更加标准化，但偶尔仍然会出现奇怪的问题。
检查日志两个小时以找出原因。
我自己没有运行这个最新版本。
我记得数据是2 .6 左右，但我建议你查看官方文档。

部分sql注入总结