I've recently heard that parametrized queries run faster on postgresql.
In an effort to test this, I decided to construct a parametrized ...
OH I can already feel the down votes. wish I knew how to ask this better... please advise before voting down :)
Does anyone know how to create a parametrized query? I can't seem to find any docs on a raw sql string that is in fact a parametrized query. I found a heap of VB || Java || php.. but these sadly don't IMHO equal sql.
To construct a parametrized query... do I have to create a function in the DB?
A nuts simple example of a query that makes use of parameters would be awesome.
The closest thing I can do to a code example would be. It doesn't come close to working.
SELECT * FROM USER WHERE ID = ? (1)
Parameterized queries are typically a function of the client framework. Different client frameworks have different semantics so your best option is to start with the client framework documentation. This being said, low-level details help so I will go over the libpq interface here. Many client frameworks wrap libpq's interface, so start with the PQExecParams documentation.
In that function, your query is transformed using placeholders indicating the parameters used. I believe these are actually sent to the db separately than the parameters which are then factored in during planning time (the planner of course is aware of the values of the arguments).
The placeholders follow a semantic structure of $1, $2, $3, etc. and so are identified by number. Other frameworks wrap this using other placeholder syntax.
Related
I like to use keyword where, for example.
I simply do it like this
Dim orderFromThisGridTrading = _orders1.Where(Function(x) x.customIdentifier = ASimpleGridTradeSettings.name).ToArray
However, most samples would say I have to use from
Dim customersForRegion = From cust In customers Where cust.Region = region
Which is weird af and don't follow normal vb.net format. That looks a like like SQL languages and not a real programming language.
I wonder if I can always avoid using Form and just use like I am using? Are there any cases where that is not possible?
Is this even a good idea?
There is nothing bad in using query syntax in general. Especially in VB.NET it is very powerful and supports a lot of LINQ methods(more than in C#). Many prefer that because it can make your code more readable. But it seems that the opposite is true for you, you don't like it. Then use the method syntax, it supports all methods. I don't like it in VB.NET because of that ugly and verbose Function keyword, especially with GroupBy or Join i prefer query syntax.
I wonder if I can always avoid using From and just use like I am
using? Are there any cases where that is not possible?
No, method syntax is always possible. Actually query syntax gets compiled to method syntax.
The second example is called "Query Comprehension Syntax". It's optional. A lot of people find it makes their code more readable, but not everyone likes it. Personally, I find it adds another extra layer of indirection for what you need to know to get the computer to do what you want.
In the first example, the "From" is implied by the intial IEnumerable or IQueryable item in the expression.
But I do have one issue:
SQL is definitely a real programming language, and you'll likely get even better results from learning it well vs needing to rely on an ORM to construct queries. Eventually, usually sooner than later, you'll find you want to do something where you need to know advanced SQL anyway. Then you have two problems, because you need to the know the SQL and you need to know how to construct the ORM syntax to produce that SQL.
I would like to create my own query language for a web api I wrote. But I have no idea where to start for it.
The language should be like SQL. For that I looked up the NHibernate code, cause I know, that they have the HQL (Hibernate Query Language) but it didn't help.
Are there any instructions or sth.? If this question is wrong here please move and/or tell me where I should ask else.
The first step is a lot of design work, starting be answering the following question:
Is this new Query Language going to be converted to SQL which will be
executed by a standard database engine, or are you going to write your
own database server as well?
If it's going to be converted to SQL (just like HQL) then map out the translations from your language to SQL on paper (and make sure you know the possible SQL constructs you may have to use). Once you've got that, you can start implementing it. Yes, this sounds like BDUF, but the language should be defined in one pass, I think, as it will be more consistent and easier to use if you do it that way. You can always implement it in a more Agile way once you've got that.
If you're going to write own database server, you're on your own....
I've recently implemented a package that uses the database/sql package. By limiting the SQL to very simple select/update/insert statements I assumed the package would work with all the DBMS supported by database/sql.
However, it turns out that some databases use ? as placeholder value while others use $1, $2, etc., which means the prepared statements will work with some DBMS but not with others.
So I'm wondering is there any technique to make this work in a generic way with all the supported drivers? Or is it necessary to have DBMS-specific code everywhere? (which I think would make the abstraction provided by database/sql a bit pointless). I guess using non-prepared statements is not an option either since different DBMS have different ways to escape parameters.
Any suggestion?
I assume this behaviour was left out specifically because SQL dialects vary significantly between databases, and the Go team wanted to avoid writing a preprocessor for each driver to translate 'GoSQL' into native SQL. The database/sql package mostly provides connection wrangling, which is an abstraction that falls under 'pretty much necessary' instead of statement translation, which is more 'nice to have'.
That said, I agree that re-writing every statement is a major nuisance. It shouldn't be too hard to wrap the database/sql/driver.Prepare() method with a regex to substitute the standard placeholder with the native one, though, or provide a new interface that specifies an additional PrepareGeneric method that guesses a wrapped sql.DB flavour, and provides similar translation.
Gorp uses a dialect type for this, which may be worth a look.
Just throwing out ideas.
I'm currently looking at some light-weight SQL abstraction modules. My workflow is such that i usually write SELECT queries manually, and INSERT/UPDATE queries via subs which take hashes.
Both of these modules seem perfect for my needs and i have a hard time deciding. SQL::Interp claims SQL::Abstract cannot provide full expressivity in SQL, but discusses no other differences.
Does it have any disadvantages? If so, which?
I can't speak to SQL::Interp, but I use SQL::Abstract and it's pretty good. In conjunction with DBIx::Connector and plain old DBI, I was able to totally eliminate the use of an ORM in my system with very little downside.
The only limitations I have run into is that it's not possible to write GROUP BY queries directly (although it's easy to do by simply appending to the generated query, and LIMIT queries are handled by the extension SQL::Abstract::Limit.
I used SQL::Abstract for a over a year, and then switched to SQL::Interp, which I've stuck with since.
SQL::Abstract had trouble with complex clauses. For the ones it could support, you would end up with a nest of "(" "[" and {" characters, which you were mentally translate back to meaning "AND", "OR" or actually parentheses.
SQL::Interp has no such limitations and uses no middle representation. Your SQL looks like SQL with bind variables where you want them. It works for complex queries as well as simple ones. I find SQL::Interp especially pleasant to use in combination with DBIx::Simple's built-in support for it. DBIx::Simple+SQL::Interp is a friendly and intuitive replacement for using raw DBI. I use the combination in a 100,000k+ LoC mod_perl web app.
Here's an argument for SPs that I haven't heard. Flamers, be gentle with the down tick,
Since there is overhead associated with each trip to the database server, I would suggest that a POSSIBLE reason for placing your SQL in SPs over embedded code is that you are more insulated to change without taking a performance hit.
For example. Let's say you need to perform Query A that returns a scalar integer.
Then, later, the requirements change and you decide that it the results of the scalar is > x that then, and only then, you need to perform another query. If you performed the first query in a SP, you could easily check the result of the first query and conditionally execute the 2nd SQL in the same SP.
How would you do this efficiently in embedded SQL w/o perform a separate query or an unnecessary query?
Here's an example:
--This SP may return 1 or two queries.
SELECT #CustCount = COUNT(*) FROM CUSTOMER
IF #CustCount > 10
SELECT * FROM PRODUCT
Can this/what is the best way to do this in embedded SQL?
A very persuasive article
SQL and stored procedures will be there for the duration of your data.
Client languages come and go, and you'll have to re-implement your embedded SQL every time.
In the example you provide, the time saved is sending a single scalar value and a single follow-up query over the wire. This is insignificant in any reasonable scenario. That's not to say there might not be other valid performance reasons to use SPs; just that this isn't such a reason.
I would generally never put business logic in SP's, I like them to be in my native language of choice outside the database. The only time I agree SPs are better is when there is a lot of data movement that don't need to come out of the db.
So to aswer your question, I'd rather have two queries in my code than embed that in a SP, in my view I am trading a small performance hit for something a lot more clear.
How would you do this efficiently in
embedded SQL w/o perform a separate
query or an unnecessary query?
Depends on the database you are using. In SQL Server, this is a simple CASE statement.
Perhaps include the WHERE clause in that sproc:
WHERE (all your regular conditions)
AND myScalar > myThreshold
Lately I prefer to not use SPs (Except when uber complexity arises where a proc would just be better...or CLR would be better). I have been using the Repository pattern with LINQ to SQL where my query is written in my data layer in a strongly typed LINQ expression. The key here is that the query is strongly typed which means when I refactor I am refactoring properties of a class that is directly generated from the database table (which makes changes from the DB carried all the way forward super easy and accurate). While my SQL is generated for me and sent to the server I still have the option of sticking to DRY principles as the repository pattern allows me to break things down into their smallest component. I do have the issue that I might make a trip to the server and based on the results of query I may find that I need to make another trip to the server. I don't worry about this up front. If I find later that it becomes an issue then I may refactor that code into something more performant. The over all key here is that there is no one magic bullet. I tend to work on greenfield applications which allows this method of development to be most efficient for me.
Benefits of SPs:
Performance (are precompiled)
Easy to change (without compiling the application)
SQL set based features make very easy doing really difficult data tasks
Drawbacks:
Depend heavily on the database engine used
Makes deployment of upgrades a little harder (you have to deploy the App + the scripts)
My 2 cents...
About your example, it can be done like this:
select * from products where (select count(*) from customers>10)