Preferowany sposób wielokrotnego wysyłania zapytań do bazy danych?

Question

Podczas korzystania z JDBC w Javie, ogólnie przyjętą metodą sprawdzania bazy danych jest uzyskanie połączenia, utworzenie instrukcji z tego połączenia, a następnie wykonanie zapytania z tej instrukcji.

// load driver 
Connection con = DriverManager.getConnection(..); 
Statement stmt = con.createStatement(); 
ResultSet result = stmt.executeQuery("SELECT.."); 
// ... 

Jednak nie jestem pewien, jak potraktować drugie zapytanie do tej samej bazy danych.

1. Czy kolejna kwerenda być wykonywane bezpiecznie na tym samym Statement obiektu lub inny rachunek musi zostać utworzony z obiektu Connection w celu wykonania innej kwerendy?

2. Jeżeli ten sam Statement przedmiot mogą być wykorzystywane do wielu zapytań, co jest celem tej klasy Statement (ponieważ byłoby to wtedy więcej sensu dla metody Connection.executeQuery() istnieć)?

Answer 1

Tak można ponownie użyć obiektu Statement, ale ResultSet obiektów zwracanych przez executeQuery zamyka już otwarty resultsets.

Zobacz javadoc za wyjaśnienie

Domyślnie tylko jeden obiekt ResultSet za Oświadczenie obiektu może być otwarty w tym samym czasie. Dlatego jeśli odczyt jednego obiektu ResultSet jest przeplatany z odczytem innego, każdy musi zostać wygenerowany przez różne obiekty Statement. Wszystkie metody wykonywania w interfejsie Statement niejawnie zamykają bieżący obiekt ResultSet, który istnieje, jeśli otwarty jest obiekt otwarty .

więc następujące zdarzenia:

// load driver 
Connection con = DriverManager.getConnection(..); 
Statement stmt = con.createStatement(); 
ResultSet result = stmt.executeQuery("select .."); 
// do something with result ... or not 
ResultSet result2 = stmt.executeQuery("select ..."); 
// result is now closed, you cannot read from it anymore 
// do something with result2 
stmt.close(); // will close the resultset bound to it 

Na przykład można znaleźć implementację open source o stwierdzenie w projekcie jTDS. W Statement.executeQuery() method widać wywołanie initialize() że closes all the resultsets już otwarty

protected void initialize() throws SQLException { 
    updateCount = -1; 
    resultQueue.clear(); 
    genKeyResultSet = null; 
    tds.clearResponseQueue(); 
    // FIXME Should old exceptions found now be thrown instead of lost? 
    messages.exceptions = null; 
    messages.clearWarnings(); 
    closeAllResultSets(); 
} 

Answer 2

No to dlaczego mamy koncepcję klas w programowaniu obiektowym. Klasa definiuje członków składowych, które umożliwiają jej instancjom stan i zachowanie. Tutaj oświadczenie dotyczy wszystkiego, co dotyczy instrukcji sql. Istnieje o wiele więcej funkcji, które można wykonywać jak zapytania wsadowe itp.

Answer 3

Programowo można ponownie użyć tego samego połączenia i tej samej instrukcji dla więcej niż jednego zapytania i zamknąć instrukcję i połączenie na końcu.

Jednak nie jest to dobra praktyka. Wydajność aplikacji jest bardzo wrażliwa na sposób uzyskiwania dostępu do bazy danych. W idealnym przypadku każde połączenie powinno być otwarte przez możliwie najmniej czasu. Następnie połączenia muszą być połączone. Przechodząc przez to, należy ująć każde zapytanie w bloku {open connection, create a prepared statement, run query, close statement, close connection}. Jest to również sposób implementacji większości szablonów SQL. Jeśli pozwala na to współbieżność, możesz zwolnić kilka takich kwerend jednocześnie, używając puli wątków.

Answer 4

Zazwyczaj jest to jedna instrukcja dla jednego zapytania.Może to nie być konieczne, ale przy pisaniu prawdziwej aplikacji nie chcesz powtarzać tych samych kroków raz za razem. To jest wbrew dyrekcji DRY, a także będzie bardziej skomplikowana, gdy aplikacja będzie się rozwijać.

Dobrze jest pisać obiekty, które poradzą sobie z takimi niskopoziomowymi (powtarzalnymi) materiałami i zapewnić różne metody uzyskiwania dostępu do bazy danych poprzez dostarczanie zapytań.

Answer 5

Nie martwię się o tworzenie nowych wyciągów. Jednak otwieranie połączenia z bazą danych może wymagać dużego nakładu zasobów, a otwieranie i zamykanie połączeń ma wpływ na wydajność.

Opuszczanie połączeń w pewien sposób samodzielnego zarządzania zwykle jest dość złe.

Powinieneś rozważyć użycie connection pooling. Zwykle wydajesz komendę close, ale tylko ty przekazujesz to połączenie z powrotem do puli. Gdy poprosisz o nowe połączenie, ponownie wykorzystasz połączenie, które otrzymałeś wcześniej.

Możesz chcieć mieć różne instrukcje dla jednego połączenia. Oświadczenie jest implementacją i interfejsem. W zależności od tego, czego potrzebujesz, czasami potrzebujesz użyć CallableStatment. Niektóre logiki mogą być ponownie wykorzystane, gdy jest to wymagane.

Answer 6

Mam jedną rzecz do dodania, jeśli korzystasz z połączenia i instrukcji w środowisku z wątkami. Moje doświadczenie pokazuje, że stmt.executeQuery (..) jest zapisywany do użycia w środowisku równoległym, ale z konsekwencją, że każde zapytanie jest serializowane i w ten sposób przetwarzane sekwencyjnie, nie przynosząc żadnych przyspieszeń. Więc lepiej jest użyć nowego połączenia (nie oświadczenia) dla każdego wątku.

Dla standardowego środowiska sekwencyjnego moje doświadczenie pokazało, że ponowne użycie instrukcji nie stanowi żadnego problemu, a ResultSet nie musi być zamykany ręcznie.