Cassandro Java kierującego QueryBuilder API vs PreparedStatements

Question

sterownik Datastax Java (Cassandro sterownik rdzeń 2.0.2) do Cassandry obsługuje PreparedStatements jak QueryBuilder API. Jakieś szczególne zalety, z których korzysta się nawzajem? Niedogodności?

Dokumentacja: http://www.datastax.com/documentation/developer/java-driver/2.0/common/drivers/reference/driverReference_r.html

Powyższy dokument nie określa żadnych zalet w porównaniu z użyciem QueryBuilder API nad PreparedStatements, inny niż pisanie zapytań programowo, co nie jest dużo korzyści (w mojej książce).

Proszę podziel się swoimi przemyśleniami i doświadczeniami. Dzięki.

Answer 1

PreparedStatements zapewnia zwiększenie wydajności, ponieważ to, co wykonujesz, jest już przechowywane po stronie serwera (zakładając, że ponownie użyjesz instrukcji). Po prostu wiążisz nowe konkretne wartości i ponownie wykonujesz instrukcję.

Kreator zapytań to bardziej zaawansowany sposób tworzenia instrukcji łańcuchowej, która ma być wykonywana bez żadnych przygotowań.

Z punktu widzenia wydajności pierwsza opcja jest najszybszy, druga i trzecia są identyczne:

// below prepared statement has already been prepared, we're now just re-using 
PreparedStatement ps = session.prepare("SELECT * FROM users WHERE uname=?"); 

1) session.execute(ps.bind('david'); 
2) session.execute("SELECT * FROM users WHERE uname=david"); 
3) session.exectute(QueryBuilder.select() 
           .all() 
           .from("users") 
           .where(QueryBuilder.eq('uname', 'david')) 

Nie jestem pewien, czy to jest istotne, ale nie jest dobrym przykładem migracji z realizacją ciąg zapytań budować z konstruktora zapytań do korzystania z gotowych gotowych instrukcji w this ycsb client.