note: this Q is looking for a comparison of Hibernate named queries and ordinary session queries. Hibernate Criteria is of no concern within the context of this Q.
from what i know, named queries are those parsed once when the system starts up, and can be used from everywhere throughout the application. so - w/named queries, the query isn't parsed from scratch for each caller of that query and this is the major gain in named queries.
but then -
is there a difference between how Hibernate operates its caches for named- and ordinary-queries? if so- what is this?
is there any loss in turning ordinary Hibernate queries into named-queries?
i've had a discussion w/a colleague. he thinks that, before i should go turning ordinary queries into named queries, i should device some metrics and write tests just to prove how named-queries is performing better.
i think this-- generating metrics and writing tests just for the sake of measuring how/whether named queries perform better than ordinary queries is nothing but burning time into something useless. that's been shown already-- the reason of existence of named queries is just getting the query parsed. what data it's pulling/changing in DB is immaterial. and, Hibernate named queries is being used by many developers.
my Q is -
am i missing something in named queries that is relevant to this discussion?
opinions on how to handle this situation? the options i'm looking at are i.) drop doing anything at all-- let queries as is, ii.) just change named queries-- reverting if disliked wont have burned too much of my time iii.) do those tests-- if i would consider this as an option.
TIA.
Short answer - Use it if you can. But if you already have queries that are working fine with tests that cover its functionality, I wouldn't recommend that you go converting them.
Another SO post addressing this can be found here:
Advantages of Named queries in hibernate?
We have a poorly designed shopping cart database. All processed objects that will be used to the front site are stored in HttpContext.Current.Cache on Application_Start. Processed objects I mean results from sql script that has many joins and where conditions.
Looking for best solution to remove caching or improve the current caching process. I'm thinking of storing the processed objects to a SQL Server table that will be repopulated every midnight. And use Dapper ORM to retrieve data from this SQL Server table and implement output caching.
Hope someone will share a high speed and maintainable solution for this problem. :)
Thanks!
What you are describing is really : duplicating the data into a second (technically redundant) model, more suitable for query. If that is the case, then sure : have fun with that - that isn't exactly uncommon. However, before doing all that, you might want to try indexed views - it could be that this solves most everything without you having to write all the maintenance code.
I would suggest, however, not to "remove caching" - but simply "make the cache expire at some point"; there's an important difference. Hitting the database for the same data on every single request is not a great idea.
I'm trying to figure out how to make implementation of android database Cursor to wrap "ORMed" database layer.
To have ORM in MonoDroid we can use sqlite-net project (very lightweight ORM) or ServiceStack.OrmLite
My thoughts are to implement ICursor interface and "wrap" ORM
For now I just can't set it in my mind how it should work, and should it work ever or not.
Should it load "framed" set of results, or fetch it one by one?
Which is better for performance, how to get column values - reflection or..?
So, actually question is: is it possible ever?
Any thoughts will be appreciated.
Thanks.
I'm not sure what "problem" you're trying to solve with an ICursor implementation, perhaps you should be a little more specific as to what specific task you're trying to do. The entire point of an ORM (and you missed this one that also supports SQLite on Android) is to abstract away the whole RDBMS paradigm from the code and give you an object-oriented paradigm instead.
An ICursor gives you back an updatable resultset from a SQL query - which means you have to know about rows, resultsets, queries and all of that. An ORM gives back an object, or a collection of objects. If you want to update one, you update the object and send it back to the ORM.
Now I fully admit that there are times when an ORM's might not provide the cleanest mechanism to do something that a SQL query might do well. For example, if you logically wanted to "delete all parts built yesterday during second shift". A lightweight ORM might give you all parts and then you have to use LINQ or similar to filter that to the right day and shift and then iterate that resulting collection to delete each, whereas with a SQL query you just pass in a DELETE FROM Parts WHERE BornONDate BETWEEN #start AND #end, but that's one of the trade-offs you face.
In some cases the ORM might provide a facility to do what you want. For example in the OpenNETCF ORM linked above, you can cast your DataStore (if it isn't already) to a SQLDataStore and then you have access to the ExecuteNonQuery method, allowing you to pass in a direct SQL statement. If still doesn't have a means to pass you back a record set because, as I said, returning database rows is really the antithesis or an ORM.
There's also some inherent risk in using something like ExecuteNonQuery. If you want to change your backing store, from say a RDBMS like SQLite to something totally different like an object database, an XML file or whatever, then your code that builds and uses a SQL query breaks. Admittedly this might not be common, but if code portability and extensibility and on your radar, then it's at least something to keep in mind.
A lot of guys on this site state that: "Optimizing something for performance is the root of all evil". My problem now is that I have a lot of complex SQL queries, many of them utilizing user created functions in PL/pgSQL or PL/python. My problem is that I do not have any performance profiling tool to show me, which functions actually make the queries slow. My current method is to exclude the various functions and take the time on the query for each one. I know that I could use explain analyze as well, but I do not think it will provide me with the information about user created functions.
My current method is quite tedious, especially since there is not query progress in PostgreSQL so I have sometimes have to wait for the query to run for 60 seconds, if I choose to run it on too much data.
Therefore, I am thinking whether it could be a good idea to create a tool, which will automatically do a performance profiling of SQL queries by modifying the SQL query and take the actual processing time on various versions of it. Each version would be a simplified one, which would maybe just contain a single user created function. I know that I am not describing how to do this clearly, and I can think of a lot of complicating factors, but I can also see that there are workarounds for many of these factors. I basically need your gut feeling on whether such a method is feasible.
Another similar idea is to run the query setting server settings work_mem to various values, and showing how this would impact the performance.
Such a tool could be written using JDBC so it could be modified to work across all major databases. In this case it might be a viable commercial product.
Apache JMeter can be used to load test and monitor the performance of SQL Queries (using JDBC). It will howerever not modify your SQL.
Actually I don't think any tool out there could simplify and then re-run your SQL. How should that "simplifying" work?
LINQ simplifies database programming no doubt, but does it have a downside? Inline SQL requires one to communicate with the database in a certain way that opens the database to injections. Inline SQL must also be syntax-checked, have a plan built, and then executed, which takes precious cycles. Stored procedures have also been a rock-solid standard in great database application programming. Many programmers I know use a data layer that simplifies development, however, not to the extent LINQ does. Is it time to give up on the SP's and go LINQ?
LINQ to SQL actually presents some alarming performance problems in the database. Basically, it creates multiple execution plans based on the length of the parameter you are using. I posted about it a while back on my blog LINQ to SQL may cause performance problems.
Now, is that to say that LINQ doesn't have a place? Hardly. LINQ definitely has a place in the development toolkit, just like stored procedures. Ultimately, you want to use stored procedures when performance is absolutely necessary and use an ORM tool in any other situation.
As far as inline SQL goes, there are ways to execute inline SQL so that the plan is only built once and is never recompiled. Most ORMs should take care of this aspect of performance tuning as well and using these methods is usually the safest way to execute your SQL since it forces you to use parameterized queries.
Like most database solutions, the right answer depends on the problem you're trying to solve. If you favor development speed over database/application performance, then using LINQ or another DAL/ORM tool is the best way to go. If you favor performance over ease of development, then using stored procedures and pure datasets is going to be your best bet. LLBLGen even provides a LINQ to LLBLGen layer so you can use LINQ to query LLBLGen's objects and have LLBLGen actually handle building your queries and avoid some of the downfalls of LINQ.
Your basic premise is flawed..
Inline SQL requires one to communicate with the database in a certain way that opens the database to injections.
No it doesn't. Hard-coding user-inputted values into a SQL statement does, but you could do that with store procedures as well.
Parameterizing your queries guards against injection attacks, but inline SQL can be parameterizing just as easily as stored procedures.
Inline SQL must also be syntax-checked, have a plan built, and then executed.
All Sql (SPs and inline) must be syntax-checked and have a plan built on their first call. Thereafter, the exact text of the request & the execution plan are cached. If another request with the exact same text (not counting parameters) is received, the cached execution plan is used.
So, if you hard-code values into inline SQL, the text won't match, and it will have to re-parse the query. However, if you use parameters, the text of the query will match, and you will get a cache hit. In which case, it wouldn't matter if the query in inline SQL or a SP.
In other words, the only problem with inline SQL is that it easy to do something that slow & insecure. But making inline SQL fast & secure is no more work that using a SP.
Which brings us to LINQ, which always using parameters, even if you hard-code the values into the LINQ statement, making "fast & secure" inline SQL trivial.
LINQ also have the advantage over SPs of having all your code in one spot, instead of scattered over two different machines.
If you're interested in benchmarking, Rico Mariani has an excellent 5-part study that covers the qualitative and quantitative differences.
He may be an MS guy, but he's known as a performance nut - his benchmarks are thorough and well thought out.
This is a performance run by Maximilian Beller. According to him, LINQ is much much slower.
Read his comprehensive study
Just think about changing a columns name - now change the (n)SPs and (x)Views.
Do everything that is expensive on the database (like searches , sorting etc..) and you won't notice a problem.
Also, if you want to display a large grid without paging ... then use a dataset - that one is faster.
StackOverflow also uses linq2sql - do you see a problem :) ?
Use an ORM - it's the way to go on most applications.
PS: also, about micro benchmarks - like .. let's select 10.000 rows with an ORM - DON'T DO IT. That's not why you use an ORM. If you want to select 10.000 rows use ADO.
It depends on what you're doing. LINQ is going to be less efficient at the actual data/set manipulation than a real database. But you'll save a lot in not having to connect to the database over a network.
If your database is on the same machine or is formally 'well-connected', you're probably better off using it.
But if you're getting back a large result set from a remote db that could mean significant transmission time, or if it's a really short query that won't justify the overhead, LINQ would likely be better.
Because of the structure of LINQ to SQL, there is no possible way it can be faster than using raw SQL, either your own well-formed queries or as a stored procedure. What LINQ buys you is not speed but type safety and organization; in short most of the benefits that ORMs generally grant you.
LINQ to SQL is not about speed, it's about building a more maintainable software system. It's about all the stuff dedicated Software Engineers and Architects care about, stuff like loose coupling and layering
That's not to say that you can't build some really unmaintainable code with LINQ -- nobody is keeping you from shooting yourself in the foot but you -- but done properly, LINQ can help tremendously. I'm not saying LINQ is a silver bullet, however. It has a host of issues that make it difficult to use in many enterprise situations -- which is why MS offers Entity Framework (ADO.NET 3.0). Of course, even that's not perfect given the recent EF Vote of No Confidence.
Is LINQ to SQL or even EF better than raw SQL? I'd say a resounding Hells Yeah. Are there other solutions that might work better? Maybe.