I am trying to execute a query against a MySQL database.
The query is fairly complex it has 5 inner joins, including 1 join to itself and
it returns 3 pieces of information from 2 different tables.
We are using hibernate and till now I have used it for simple queries only.
I have written the sql query and tested it too. I am wondering how to implement this using
hibernate, can I execute plain sql statements with hibernate? If so what do I need, a separate hbm.xml?
If I use hibernate and execute the plain sql query can I still utilize caching later on?
Yes, you can execute plain SQL queries with Hibernate.
No, you don't need a separate hbm.xml mapping file (unless you WANT to separate sql queries from the rest, in which case you can do so). You can map your named SQL query the same way you do with named HQL queries.
Whether you will be able to "utilize caching" depends on what exactly you understand by "caching" and how you're going to map your SQL query; it's impossible to answer without knowing more details.
All that said, you may not need to resort to SQL query; HQL is quite powerful and it may very well be possible (assuming appropriate mappings exist) to write your query as HQL. Can you post relevant mappings / schemas and your SQL query?
I strongly recommend criteria queries over HQL queries. They are much closer to your program code without sacrificing any expression power. They DO however depend on relations to be explicitly mapped, otherwise they get quite complicated.
To speed up development, set property hibernate.show_sql=true, and play with the system in the debugger, using the "reload modified class" and "drop stack frame" features of the IDE+jvm until the SQL emitted looks like the one you've posted.
Related
In the go sql package, I understand that each statement should be closed after execution.
Why would someone use prepared statements instead of just the raw Query or Exec methods?
Prepared statement already bound to concrete connection to DB, contains low-level driver.Stmt and can be used concurrently by multiple go-routings. So it's quite handy to prepare and use, and things work faster.
I think the best answer comes from the wikipedia article on Prepared Statements.
Quoting:
The overhead of compiling and optimizing the statement is incurred
only once, although the statement is executed multiple times. Not all
optimization can be performed at the time the prepared statement is
compiled, for two reasons: the best plan may depend on the specific
values of the parameters, and the best plan may change as tables and
indexes change over time.`enter code here
Prepared statements are resilient against SQL injection, because
parameter values, which are transmitted later using a different
protocol, need not be correctly escaped. If the original statement
template is not derived from external input, SQL injection cannot
occur.
When dealing with SQL Server and dates that are clustered indexes, in order to properly access the index the query must be in the form of:
select fields
from dbo.MyTable
where myDate between #begDate and #endDate
The between operator is what triggers the clustered seek. How can I tell LINQ to emit the between operator instead of >= this and <= that?
Unfortunately, Linq does not have a between operator or equivalent. The best (and possibly) only way to achieve this is in sql.
If you are looking to write complex or optimized queries, it is better to use sql rather than linq. The main advantages for this are:
Code can be fully tested in management studio, without having to translate and debug in a second language
For legacy purposes, it is generally better to use sql for database access code, as this is more widely known amongst database experts. LINQ is the curse of DBAs who have to manage/support code written by others.
I agree with Gerge Mauer's suggestion to use a stored procedure or ADO.
This might still leave you with the problem of parameter sniffing, in which case you may have to use query hints such as OPTIMIZE FOR / RECOMPILE, or local variables to get around this, as demonstrated in this article:
http://blogs.msdn.com/b/turgays/archive/2013/09/10/parameter-sniffing-problem-and-workarounds.aspx
I work in a project where the UI has direct access to the database through SQL code. The company has a framework where we create UI pages in xml and after that it is parsed and creates FLEX pages. If we want some data from the DB (Oracle) we add a sql query in the xml (instead of databinding with a datacontext object like we could do with WPF). If we want to add some logic, there is no code behind, we call store procedures. After we have the data we need the parser does the job.
The new requirements are to use the framework and create a new product that will be compatible with SQL Server and the thoughts are to start transforming the (Oracle)SQL queries to ANSI SQL.
Can somebody tell me the benefits and mainly the problems that we are going to face doing that?
Do you think there is a better way?
Note: The framework is really big and there are a lot of products built on that so managers are not keen to just throw it away(I tried but.. :))
Each dialect of SQL is different. You could use ANSI SQL but a) not all of ANSI SQL is implemented by most DBMS and b) most DBMS's have implementation-specific optimisations which will perform better for some cases.
So I'd say, don't go for ANSI SQL. It won't always work and sometimes it will work slower than taking advantage of a vendor's non-standard implementations.
Specifically, Oracle requires a StoredProcedure to return a REF_CURSOR from a stored procedure to fill a DataSet. SQL Server doesnt; the SP returns what the sp SELECTed. You're going to have to change your SP's to get rid of the returned REF_CURSOR.
Date handling is quite different: Oracle needs a to_date to turn a string into a date in where clauses etc; SQL Server just takes the string and converts it for you. And so on and so on. (I'm not at all sure what the ANSI Standard is, or even if it covers this!) To avoid changing your SQL you could add create SQL Server function called to_date, but this is now going to slow up your SQL.
If you have much PL/SQL in stored procedures, you have a big job converting it to T-SQL. They are quite different.
Good luck!
I want an easy way to generate SQL queries in Ruby. I know all about ActiveRecord, Sequel and DataMapper. I'm not looking for an ORM but just an easier way to generate SQL statement strings.
I'm using RBHive to run Hive queries and would like an easy way to generate the Hive query statements.
Surely this exists (AR, etc) and I've looked at Arel, which seems promising. But can't figure out how to strip the SQL statement generation pieces off of the popular ORM libraries. Everything requires a connection to a database server.
Currently I just use raw SQL strings, but I want to get away from that as the queries are becoming more and more complex and error-prone.
Any ideas?
You said
Everything requires a connection to a database server.
I think, at least with Sequel you can use a dummy Database:
require 'sequel'
DB = Sequel::Database.new() #-> <Sequel::Database: >
puts DB[:test].sql #-> SELECT * FROM "TEST"
You're right, you're looking for Arel, which is used to build an AST for SQL statements and does not require a database connection.
The syntax is pretty different from what you're used to seeing, though. So be aware.
Read the README here to see if it makes sense to you:
https://github.com/rails/arel
Do linq generated queries get cached effectively by SQL Server 2008?
or is it better to use stored procedures with linq or what about a view and then using compiled linq queries... opinions?
cheers
emphasis here is on "effectively", and or is it better....
ie. views are cached well by sql server, and then using linq on the view....
On top of the answers already given according to Damien Guard there's a glitch in the LINQ to SQL and EF LINQ providers that fails to set the variable lengths consistently for queries involving string parameters.
http://damieng.com/blog/2009/12/13/sql-server-query-plan-cache
Apparently it's fixed in .NET 4.0.
In the past I've written stored proc's in place of LINQ queries, mainly for complex reporting-like queries rather than simple CRUD but only following profiling of my application.
L2S simply passes queries on to SQL Server 2008. So they will get cached, or not cached, like any other query submitted by any other process. The fact that a Linq query is compiled has no impact on how SQL Server processes the query.
Queries that LINQ generates are normal SQL queries like your own hand-crafted SQL queries, and they follow the same rules: if the query text is identical (down to the last comma and whitespace) than a query text before, chances are its query execution plan might have been cached and thus able to be reused.
The point is: the query text has to be absolutely identical - if even a single whitespace is different, SQL Server considers it a new query and thus will go through the full process of parsing, analysing, finding a query plan and executing it.
But basically, yes - queries sent off by LINQ will be cached and reused - if they meet those criteria!