Доступ к данным через JDBC
JDBC (Java Database Connectivity) — стандартный низкоуровневый API, через который Java-код общается с реляционной базой данных. Всё построено вокруг трёх сущностей: Connection (соединение с БД), Statement/PreparedStatement (запрос) и ResultSet (курсор по строкам ответа). ORM вроде Hibernate и Spring Data — это надстройки, которые в конечном счёте выполняют те же JDBC-вызовы.
Практически весь смысл темы упирается в один вопрос собеседования: чем Statement отличается от PreparedStatement и почему второй — выбор по умолчанию. Ответ связывает две вещи разом — безопасность (защита от SQL-инъекций) и производительность (прекомпиляция и переиспользование плана). Разбор — в слое ниже.
Карта темы
- Statement и PreparedStatement —
Statementшлёт строку целиком,PreparedStatement— шаблон с привязанными параметрами; почему это закрывает инъекцию и ускоряет повторные запросы.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Собирать SQL конкатенацией пользовательского ввода | Открытая SQL-инъекция: ввод ' OR '1'='1 возвращает все строки таблицы |
| Считать ручное экранирование кавычек заменой привязке | Экранирование хрупко и обходится; надёжна только привязка параметров |
| Путать, какой из них параметризован | Параметризован и безопасен PreparedStatement, а не Statement |
| Полагать, что производительность одинакова | PreparedStatement компилирует план один раз и переиспользует его |
Не закрывать ResultSet/Statement/Connection | Утечка ресурсов и соединений — используйте try-with-resources |
Значение для собеседований
JDBC редко спрашивают глубоко, но Statement против PreparedStatement — почти обязательный вопрос джуниор- и мидл-уровня: он проверяет понимание SQL-инъекций сразу с двух сторон — как их создают и как закрывают.
Что обычно проверяют:
- Чем отличается отправка полной строки SQL от параметризованного шаблона.
- Почему привязанный параметр не может быть истолкован как часть синтаксиса SQL.
- Почему ручное экранирование — не замена привязке параметров.
- Что даёт прекомпиляция и когда переиспользование одного
PreparedStatementокупается.
Типичный неверный ответ: «PreparedStatement просто экранирует кавычки за вас». Нет — значение вообще не попадает в текст запроса: БД сначала компилирует шаблон с плейсхолдерами, а данные подставляются отдельным каналом как типизированные параметры, поэтому парсер SQL их не видит.