Does anyone has the data of speed comparison between Eloquent ORM, Query Builder, and Raw SQL Queries? What is the better choose?
Raw SQL will always be the fastest because a human can always optimize the code and script to their liking. The query builder (aka Fluent) will be the next fastest, only slightly slower than Eloquent. That's because Eloquent uses Fluent within itself along with its own models and relationships.
If you're looking for pure processing speed, use raw SQL.
Otherwise use Eloquent for fastest development UNLESS you have no models and relationships, then use Fluent.
Related
What's the best way to work with complex queries? it is sometimes difficult to use Eloquent to query multiple tables
I am Working on multiple database like MSSQL server and PostgreSQL with heavy transactions and complex queries. I have searched that simple jdbc is more faster then ORM. I was thinking of using ORM because I do not want to write different query for different database for same work, and also for standardized my dao layer. I am mapping my database tables without using foreign keys and for ORM like apache cayenne I have to map tables with foreign key constraint, so I can use my Joins or any other multiple table operations. Is it good to use and ORM or simple jdbc is fine.
From your problem dscription, you already have an understanding of the tradeoffs involved. So this is really a decision that you need to make for yourself based on those tradeoffs.
My only advice here will be to take a second look at performance requirements. While ORM does introduce an overhead of creating, storing and managing objects, in all but a few cases, you can safely ignore this overhead for the sake of a better abstraction. Also when working with JDBC very often you end up writing your own code to convert ResultSet to objects, which will encounter its own overhead. So you may not end up with faster code, while forfeiting all the benefits of a clean object model and a framework that manages it.
So my own preference is to go with a better abstraction (ORM in this case), and then use the framework tools for optimizing the performance. E.g. to speed up processing of large ResultSets Cayenne provides a few techniques: result iterators, DataRow queries, paginated queries, etc.
On the other hand I would use JDBC or something like MyBatis when it is not possible to cleanly model your data as entities. E.g. when there are no natural relationships, all access happens via stored procedures, etc. Doesn't seem like your case though.
I have multiple migrations (say around 10) and the corresponding models for the tables. The problem I am facing is that all the migrations/tables have multiple primary keys but the model has just a string variable to define primary key ($primaryKey), hence, when I save or update a table row using where clause it would just take one primary key and miss the other and hence end up changing multiple rows instead of one. So, basically I switched to DB Queries and it worked well.
So, my question to you is that is there any performance gain with model? Or it is just a designing paradigm? Is there any option to do the same thing (Have multiple primary key) within a model? I know by overriding the Eloquent methods we can do this but is there any other good option?
Using an ORM like Eloquent is a convenience, not a requirement. From what I've heard there's actually often a slight performance decrease when using an ORM because there's the additional overhead of translating that query into the relevant SQL.
Often, using an ORM makes for queries that are much easier to understand, and for that reason alone it's worth using. However, for more complex queries, an ORM is likely to get in the way, and so you should consider using another method to query the database. You don't have to use just an ORM - you can mix and match the different methods as you see fit.
Laravel has the Query Builder as an alternative to writing raw SQL or using the ORM, and that may be a better option for you here. I would avoid writing raw SQL if you can because both Eloquent and the Query Builder will handle escaping the parameters for you, to help avoid SQL injection vulnerabilities.
My choice would be to use the ORM where possible, and fall back to the Query Builder when the ORM gets in the way.
I have an SQL query with joins. I want to use Linq. some one suggested me to avoid joins and use Linq include. How can I combine entities using Linq include? Is there a better way than joins ?
Thanks
LINQ to SQL converts LINQ syntax to an SQL query. If the query requires a Join, then LINQ to SQL will actually execute an SQL query with joins against the database. The advantage you may gain is that the LINQ to SQL query may be more optimized than the one you have written.
If you are not familiar with using LINQ and you have a working application, you will probably not gain anything other than complication by adding an additional layer of abstraction (LINQ). That being said, LINQ is an excellent and powerful tool. However, that doesn't change the truth to the adage "If it ain't broke don't fix it."
Basically, what you are considering is converting your application's data access procedure from
app -> SQL Query with Joins -> data objects
to
app -> LINQ Query with Joins -> SQL Query with Joins -> data objects
I am pretty well versed in both, and I think writing LINQ queries is a lot easier than writing SQL queries. (You get strongly typed models and Intellisense). However, if you only know SQL, then writing an SQL query is significantly easier than learning LINQ and writing a LINQ query .
Note that LINQ also supports joins. Here is an article on using joins in LINQ: http://odetocode.com/Blogs/scott/archive/2008/03/25/inner-outer-lets-all-join-together-with-linq.aspx .
I would like to apply a Criteria query to an in-memory collection
of entities, instead of on the database. Is this possible?
To have Criteria API work like LINQ? Or alternatively, convert
Criteria query to LINQ query.
Thanks!
I don't believe you can use Criteria to query against an in-memory collection and come to think about it it doesn't seem to make much sense. If I'm understanding everything correctly you've already queried against your database. I'd suggest to either tune your original query (whichever method you choose) to include all of your filters. Or you could use LINQ (as you suggested) to refine your results.
Also, what's your reasoning for wanting to query from memory?
It sounds like you're rolling your own caching mechanism. I would highly recommend checking out NHibernate's 2nd level cache. It handles many complex scenarios gracefully such as invalidating query results on updates to the underlying tables.
http://ayende.com/Blog/archive/2009/04/24/nhibernate-2nd-level-cache.aspx