Each form has advantages and disadvantages.

Text file

At the time when I was developing a framework in PHP, I thought a lot about the possibility of storing queries in text files.

This would reinforce the separation of concepts, that is, I did not want to worry about the syntax of PHP mixed with SQL.

However, after considering the impact of reading and processing the files, I gave up the idea.

Separate PHP file

I used this approach in a project and found it very interesting. Each class had a PHP file with queries in strings. heredoc is an interesting representation of this approach.

The advantage is that you can get an overview of queries , making SQL refactoring easier, and your code gets cleaner. The downside is that sometimes you need to keep switching files multiple times to see the contents of the variables.

Queries inline

Today I avoid to the utmost, in any language put the queries directly inside a function or method.

First because with SQLs distributed in the middle of the code, if the table changes, I often forget to update one of the "lost" queries in files and methods.

Second, because although it works well for queries very simple, it usually ends up "spoiling" the formatting of the code and "breaking" the flow of the code, disrupting its reading.

Representing SQL in String

To represent SQL in a PHP String, I would avoid to the maximum the way it concatenates line by line. This is asking for a tendinitis.

Using multi-line quotes, it does not look so ugly if you do not use tabs. Example:

<?php 
$sql = "
SELECT *
FROM usuarios u
ORDER BY u.nome";

The only problem of the above String is a line break at the beginning.

The heredoc format seems to me to be the most interesting. First because there is no problem with the line break or formatting. Also, it allows you to copy and paste the query easily, which I consider important, since I do this frequently during development.

Once you get used to it a bit will not seem so strange. ;)

On the other hand, as mentioned in the question itself, there is still the Nowdoc format. According to the documentation, it works as single quotation marks, where the content is not parsed and therefore variables are not interpolated. The use of Nowdoc is interesting because it avoids unnecessary processing on "constant" strings, that is, it does not have PHP variables inside.

General considerations

Adopting a pattern where to store queries facilitates developers' understanding of the system and avoids the introduction of bugs , as there are no SQLs sprinkled by the code. p>     

I used a normal tabbed form, but today I've used the dibi class a lot, it's an extremely powerful, lightweight and useful database wrapper and layer abbstraction ...

link

The class also supports fluent programming, which is extremely handy for maintenance, for example:

My normal select would look like this:

  

$ sql="        SELECT *        FROM users u        ORDER BY u.name ";

Do not dibi fluently you can use this way:

  

$ result =   dibi :: select ('*') -> from ('users') - > as ('u') -> orderBy ('u.name') -> fetchAll ();

There's also a way to do it in a very practical way, like this:

  

$ reset = dibi :: query ('SELECT * FROM [users] AS [u] ORDER BY   [u]. [name] ')

Note that the second time I put brackets because postgree uses the columns as "u". "name" then dibi checks if you are using PGSQL or MYSQL since it is abstraction and if it is mysql it takes the [] if it is PGSQL it converts the [] to ""

Finally it's practical and I can change my db from PGSQL to MYSQL or SQL Server or others without having to change practically any code ...

I think it's worth checking the class is very good ... Strong hug.

I always use this method:

$sql = "
 SELECT *
 FROM usuarios u
 ORDER BY u.nome";

I find it easier and less prone to error!

I think there is not a more correct form, I usually write in a same line, some organize in several to make it easier to read, but if the topic is organization I would say that I like the way you write in Zend, so you write object oriented and at the end the result is a normal query in a single line:

Example