I am building application which needs to have OOP style MySQL query builder. I want to be able to flexibly build complex queries using only PHP and to get resulting query string for execution with my own database driver.
Does anyone know of a good standalone query builder for PHP? Please note that I don't need database driver I need bare MySQL query builder class (preferably written with camel style function and variable names).
Finally I took Doctrine ORM
and modified it little bit to build SQL instead of DQL.
This works very nice and it able to construct complex queries.
Edit:
You can find my final stable implementation in Stingle framework. Look at Db/QueryBuilder plugin.
DSQL - Query Builder for PHP is exactly what you're looking for, no dependencies and has MIT license:
$query = new atk4\dsql\Query();
$query ->table('employees')
->where('birth_date','1961-05-02')
->field('count(*)')
;
echo "Employees born on May 2, 1961: ".$query->getOne();
https://github.com/atk4/dsql
Documentation: http://dsql.readthedocs.io/
The PhpToolCase library has a stand-alone query builder tool that is quite easy and handy to use.
There is full join support aswell: http://phptoolcase.com/guides/ptc-qb-guide.html
And ya, it seems to be written with camel style function and variable names :)
There is one version of query builder there (LGPL licenced). I haven't used it, but you might want to take a look at it, if it suits your purposes:
http://code.google.com/p/mysql-query-builder/
Related
I have a table with a JSON column, it's type longtext (DC2Type:json). This table has an Entity in Doctrine ORM in my Symfony project. I would like to query based on fields inside the JSON column, using the Doctrine query builder I have in a variable $qb
How do I do this? Everything I found online says to install a 3rd-party package to enable this. Is there no way to just do it with Doctrine's query builder without installing another package?
One (maybe dumb) workaround I tried was to treat the column as a string, and do...
$qb->andWhere("my_data LIKE \"%id:\\\"1,%\"");
For example, if I wanted to query the JSON column my_data to find the blobs that contain id":1, in the string. This fails with a very strange syntax error, and isn't the right way to query a JSON field anyway. HOWEVER, doing the LIKE query directly in SQL client works the way I want, so I also don't know why this is failing in Doctrine.
EDIT: This is MySQL / MariaDB.
Doctrine Query Language is pretty limited. It covers only the most basic/common SQL functions, which is enough for like 99% use cases, but not all.
If you have a MariaDB version that natively supports JSON (so 10.2 or later) you can use native functions to work with the JSON data. (If you don't then your workaround is the only option regardless, with perhaps some additional filtering in the application).
To be able to use these functions in DQL you either need to define them yourself or indeed use a third party library like scienta/doctrine-json-functions (note that it has documentation for how to use it with Symfony, and it's really simple).
If you need just a single extra function and for some reason don't want the whole bundle, you could just copy that single class and use it as your own.
Alternatively you can forgo DQL and write SQL directly, but that way you can't hydrate into objects directly and use other Doctrine magic with the data. But it can be enough for simple use cases.
Im looking over inherited code with the following (partial) class:
class Model_UserGenre extends Zend_Db_Table_Abstract {...
$select = $this->select()->from(array('ug' => $this->_name), array('user_id'))
->where('genre_id IN (?)', $genreID)
->orwhere('sub_genre_id IN(?)', $genreID)
->group(array('ug.user_id'));
$result = $this->fetchAll($select);
return $result;
...}
This is just a sample code. I am unfamiliar with Zend and have tried to read up on the zend db methods cursorily but to me it seems unnecessarily complicated vs just putting in the query string when I am not using a fully dynamic query
Does zend, especially in this case, present some kind of dynamic capability or efficiency that a direct mysqli or PDO query does not?
Thanks and sorry for the noobish question.
The query builder is just there as a usability layer on top of a PDO. It provides some convenient functionality a PDO does not, like dealing with IN statements. It is also there to implement the adapter design pattern, where your database driver can be very easily swapped out.
Essentially, A PDO will still require you to write raw SQL whereas the query builder will do that for you. Any SQL generated by the query builder will be valid for any SQL adapter the query builder supports (eg. PostgreSQL, MySQL, SQLite).
Can someone provide me a couple clear (fact supported) reasons to use/learn DQL vs. SQL when needing a custom query while working with Doctrine Classes?
I find that if I cannot use an ORM's built-in relational functionality to achieve something I usually write a custom method in the extended Doctrine or DoctrineTable class. In this method write the needed it in straight SQL (using PDO with proper prepared statements/injection protection, etc...). DQL seems like additional language to learn/debug/maintain that doesn't appear provide enough compelling reasons to use under most common situations. DQL does not seem to be much less complex than SQL for that to warrant use--in fact I doubt you could effectively use DQL without already having solid SQL understanding. Most core SQL syntax ports fairly well across the most common DB's you'll use with PHP.
What am I missing/overlooking? I'm sure there is a reason, but I'd like to hear from people who have intentionally used it significantly and what the gain was over trying to work with plain-ole SQL.
I'm not looking for an argument supporting ORMs, just DQL when needing to do something outside the core 'get-by-relationship' type needs, in a traditional LAMP setup (using mysql, postgres, etc...)
To be honest, I learned SQL using Doctrine1.2 :) I wasn't even aware of foreign-keys, cascade operations, complex functions like group_concat and many, many other things. Indexed search is also very nice and handy thing that simply works out-of-the-box.
DQL is much simpler to write and understand the code. For example, this query:
$query = ..... // some query for Categories
->leftJoin("c.Products p")
It will do left join between Categories and Products and you don't have to write ON p.category_id=c.id.
And if in future you change relation from one-2-many to let's say many-2-many, this same query will work without any changes at all. Doctrine will take care for that. If you would do that using SQL, than all the queries would have to be changed to include that intermediary many-2-many table.
I find DQL more readable and handy. If you configure it correctly, it will be easier to join objects and queries will be easier to write.
Your code will be easy to migrate to any RDBMS.
And most important, DQL is object query language for your object model, not for your relational schema.
Using DQL helps you to deal with Objects.
in case inserting into databae , you will insert an Object
$test = new Test();
$test->attr = 'test';
$test->save();
in case of selecting from databae, you will select an array and then you can fill it in your Object
public function getTestParam($testParam)
{
$q=Doctrine_Query::create()
->select('t.test_id , t.attr')
->from('Test t ')
$p = $q->execute();
return $p;
}
you can check the Doctrine Documentation for more details
Zeljko's answer is pretty spot-on.
Most important reason to go with DQL instead of raw SQL (in my book): Doctrine separates entity from the way it is persisted in database, which means that entities should not have to change as underlying storage changes. That, in turn, means that if you ever wish to make changes on the underlying storage (i.e. renaming columns, altering relationships), you don't have to touch your DQL, because in DQL you use entity properties instead (which only happen to be translated behind the scenes to correct SQL, depending on your current mappings).
I'm working on a php service.
I'd like to pass an object with the parameters to use in the "where" clause and also the "order" and "limit" params.
I'm wondering whether there is a standard way/library to make up the query based on the parameters given, or whether I'll need to roll one.
I'm using ezsql to connect to mysql.
Any pointers, much appreciated.
Writing one yourself shouldn't be too hard. If you don't want to do so (DRY, right?), you may check out sites like phpclasses.org or use an abstraction layer from Doctrine (take a look at its QueryBuilder if it is what you need)
Another suggestion if you would like to use already existing code: Zend Framework has a "query builder", Zend_Db_Select.
This does not require the whole Zend Framework, but it does have some depedencies you will have to include.
Documentation: http://framework.zend.com/manual/en/zend.db.select.html
I am working on an architecture redesign at my work and we've basically settled on a loosely-basic MVC custom solution. The intentions are to have the standard CRUD operations plus additional list operations defined in each of the models in our system.
Unfortunately about 30% of the code in our system uses complex joins and otherwise advanced querying that doesn't fit this model. Which is to say it could fit the model, but the list function would be huge and certainly error prone which is something we are trying to solve with the rewrite.
Given that, where would you place complex and very specific queries in such a system? We've been toying with a few options.
Add multiple versions of list/get in addition to the basic ones
Add in custom models for these queries that reside as siblings to the model directory
Don't use models in this situation and add the work directly in the action
We have outsourced help as well so we are attempting to keep it as simple as we can in terms of implementation and maintainability. ORM solutions or other heavyweights are out of the question.
Where would you want to see such things placed as a developer?
I apparently lack the privileges necessary to comment, so I'm posting this as answer...
Could you provide an example or two of the kinds of queries you have that don't fit into a model? Generally speaking: a good ORM will get you a long way, but some queries really are just too hairy to map easily, and if your team already has strong SQL skills the ORM can also seem like it's getting in the way.
First , all you're queries should stay in you're model .
Second , most of mvc frameworks provide more than just simple crud for you're database operations like a query functionality that where you can pass the query string , in this case you can build you're queryes manualy or with a query builder like for example Zend_Db_Table_Select and that handles multiple joins prety well . Or again if we look some place else than Zend let's say Codeigniter , it still provides a query builder for the model where you can add you're joins or build any other kind of complex queries .
That being sayd , it looks like you're base model class ( the one you extend each of you're models ) needs a query builder functionality , then you should be all good as you would be able to build any query you like inside any model you like .
I have similar issues in am MVC framework I've been building from scratch.
I don't particularly like the overhead of SELECT * on complex queries so I didn't build any of that functionality in whatsoever.
It's slower to code, but I code every query by hand in the relevant class (my model calls a Class 99% of the time).
For really complex queries shared amongst various routines, I have functions that return the generic joins and then concat the additional parameters for that particular query.
Example provided as requested:
private function returnFindClientRequests(){
$query = "SELECT
SR.sign_project_name, SR.module_signregister_id_pk
,SRI.module_signregister_sign_id_pk,SRI.sign_location_address
,SRR.status, SRR.module_signregister_item_client_request_id_pk, SRR.client_comment, SRR.requested_by_user, SRR.date_created
,SRR.admin_comment, SRR.date_actioned
,CL.client_name, CL.module_client_id_pk
FROM
`module_signregister` SR, `module_signregister_item` SRI, `module_signregister_item_client_request` SRR, `module_client` CL
WHERE
SR.module_signregister_id_pk = SRR.module_signregister_id_pk
AND SRR.module_signregister_sign_id_pk = SRI.module_signregister_sign_id_pk
AND SRR.requested_by_group = CL.module_client_id_pk
AND " . Database::groupQuery('CL');
return $query;
}
This query is shared amongst some other functions but also uses a call to Database::groupQuery() that us used to return session specific variables to many of the queries.
Models are workers - if you have 100 reports you're potentially going to need 100 models. Joins have nothing to do with MVC - how your data is addressed is another pattern altogether. If you're not using ORM and you're not using active records then all that's left is sending the SQL straight to the server via a model. Probably via a dedicated database class but the model will handle the query and its results.