Im new to Laravel and have been reading up on its query builder, however haven't been able to find a definite answer. I know that stored procedures are essentially like functions that are stored inside the database to increase performance and security, but does Laravel's query builder work as a replacement for that?
Essentially, would it be necessary to use both stored procedures AND the Laravel query builder, or would using the query builder be enough since the functions are already built into Laravel?
Query builder is not a replacement of stored procedures. It works using PHP PDO. Stored procedures are a set of SQL queries in the compiled form. It helps to reduce network traffic and improve performance.
Related
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 currently have a SQL query that needs to be rewritten in C# code that interrogates 2 different sharepoint lists.
Given that this query filters using the SQL year() function, has multiple unions and subqueries, how should I be writing this in code? CAML queries or LINQ seem excessive and slow when the query will be converted back into SQL to be run anyway (the lists in question are actually tables surfaced as lists through Access Services, so it seems stupid to convert a database query into code, in order to run a database query!)
I ended up doing this by importing all the data from the relevant table's lists into an in-memory SQLite database, using the client object model, and then running a modified SQL query on the SQLite tables. As there wasn't that much data this was an acceptable method.
I want to store some user data in memory, like some in-memory noSQL database.
But later on I want to query that data with a dynamic query constructed from the user. That query is stored in a classic DB like a string, so when I need to query the data stored in memory I would like to parse that string and construct the desired query (by some known rules).
I looked at Redis and I figured out it isn't maintained for Windows anymore, I have also looked at RavenDB but it's main query language is LINQ, even though it can be created dynamic Lucene Query.
Can you suggest me another in memory DB that work with ASP.NET and can be queried with a dynamically created query? Maybe I haven't seen all the options.
I prefer name-value or JSON based noSQL so it's schema can be easyly modified without the constraints of the relation type of DBs
I would suggest to simply use sqlite. It can be easily used as an in-memory database (just open the database using ":memory:" instead of a file name).
You can use a simple 2 columns table with a primary key to emulate a key/value store.
Here are a few links you might find helpful:
http://www.sqlite.org/inmemorydb.html
How to create asp.net web application using sqlite
I'm not so good at both Linq and SQL. But I have worked more with SQL and less with LINQ. I've gone through many articles which favors LINQ. I don't want to go the SQL way (i.e. writing stored procedures and operating data etc.)
I want to start with LINQ for every operation related with data. Here are the reasons why I want to do this:
I want to have complete control of my database via application and not by writing stored procs (as I'm not so good at writing store procedure)
I want to create my project as an easy maintainability view
Want faster development
For that, I know that:
I need to add a dbml file, drag and drop tables into that
Use dbContext class, and so on
But I want to know, is there a way:
I can avoid creating dbml file and still be able to access the database?
Do I need to use Linq to Entities for the same?
Will it be a good way to avoid using dbml file? Since for every database changes I need to drop and drop tables every time
Also I've come across many posts where linqToSql is considered deprecated and not a .net future?
I have so many doubts, but I think that's obvious when starting with a new technology?
I found this useful article which is good for beginners:
[http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx][1]
after doing some more research I came to conclusion that:
1)i can avoid creating dbml file and still be able to access database??
ANS Yes but instead of dbml now edmx files will be created.
2)Do I need to use Linq to Entities for the same?
ANS Yes you can go with linq to entities.
3)Will it be good way avoid using dbml file? since for every database changes I need to drop and drop tables every time
ANS it is not required to drop and create again the tables. their are options where you can update selected part of your database and you are not avoiding dbmls. it will created edmx file and that will almost similar to dbmls in many ways.
4) Also I've come across many posts where linqToSql is considered deprecated and not a .net future?
ANS yes in future development it will be depreciated. it supports only sql server as backend.
I hope I'm right. Please do tell me in case any other suggestions.
LINQ is a way to query and project collection of data. For example, you can use LINQ to query and shape data from a database or from an array. LINQ by it self has nothing to with the under lying database.
You use an ORM (Object Relational Mapper) technology to project data stored in tables of a database as collections of objects. Once you have the collection of objects, you can use LINQ to query them.
Now, you have many ORM technologies to select from, such as Entity Framework, NHibernate, Linq2Sql. If you don’t like to maintain a dbml file, have a look at code first approach offered by Entity Framework.
Then there are things called LINQ data providers. They would take a LINQ query, transform it to a SQL targeting a particular database, execute the query and get the results back as a set of objects. Many of the ORMs above has built in LINQ data providers as a part of them and would work behind the scene in fetching the data.
I would advise you to look up on some patterns such Repository and Unit of work for your data layer. When used correctly, these patterns will isolate your data access code from your applications upper layers. This will help you to change your data access technology is it becomes obsolete, without affecting the rest of the application.
LINQ is an awesome technology and you should definitely try it
I have composed the above answer based on my own experience and I am sure there are many SO users with better understanding of the above technologies than myself who may wish to add their own opinion
Good luck
I have to make some filters, such as get persons who are in a given department, and I was wondering about the best way to do it.
Some of them are going to require the join of multiple tables.
Does anyone know about the main differences between CDbCriteria and Query Builder? I would particularly like to know about the compatibility with databases.
I found this in the Yii documentation about Query Builder:
It offers certain degree of DB abstraction, which simplifies migration to different DB platforms.
Is it the same for the CDbCriteria objects? Is it better?
The concept of CDbCriteria is used when working with Yii's active record (AR) abstraction (which is usually all of the time). AR requires that you have created models for the various tables in your database.
Query builder a very different way to access the database; in effect it is a structured wrapper that allows you to programmatically construct an SQL query instead of just writing it out as a string (as an added bonus it also offers a degree of database abstraction as you mention).
In a typical application there would be little to no need to use query builder because AR already provides a great deal of functionality and it also offers the same degree of database abstraction.
In some cases you might want to run a very specific type of query that is not convenient or performant to issue through AR. You then have two options:
If the query is fixed or almost fixed then you can simply issue it through DAO; in fact the query builder documentation mentions that "if your queries are simple, it is easier and faster to directly write SQL statements".
If the query needs to be dynamically constructed then query builder becomes a good fit for the job.
So as you can see, query builder is not all that useful most of the time. Only if you want to write very customized and at the same time dynamically constructed queries does it make sense to use it.
The example feature that you mention can and should be implemented using AR.