Let me start off by saying I love using ORM whenever I can.
Extremely simple and quick to write. Perfect for most CRUD.
Often though I have different needs and Use DB.
Sometimes I use Query Builder, but lately I have simply been using DB::query($sql)->execute;
Especially if I am doing JOINS, GROUPS and using any MySQL Functions.
It feels like I create some SQL, test my queries, then covert that to a builder set, which in turn converts that back to SQL. It seems like a lot more work for no advantage that I am aware of. But maybe that is just it. What don't I know? :)
I want to make sure I understand what I am giving up.
My understanding is the only thing I am really loosing is portability to another DB Engine.
I have no plans of changing DBs for a while on most projects.
Well maybe from MySQL to MariaDB but hopefully that will be smooth for a long time to come.
Using a QB should give you a reasonable abtraction of the underlying platform.
If you carefully design your application and follow the rules for separation-of-concern, all I/O is concentrated in methods inside your models, and not littered all over your controllers. Which makes changing the DB layer a relatively painless operation.
You could skip the QB, and code your SQL yourself. You gain a little bit of time (because in the way you work you don't have to convert), you can contain the complexity if you keep your code in the model, and you'll lose a little bit of time when you have to make changes.
I'd say: - No matter what your I/O backend is, separation of concerns! - use ORM where possible. It develops faster, and it's easier to maintain - use QB combined with as_object() to return ORM models from complex queries - use QB if you do bulk operations, complex selects (for lists/reports) or complex operations - use hardcoded SQL is all else fails
And if performance is an issue, always code for speed. Any layer you add uses clock ticks.
For me, and most (enterprise) clients, this is never an issue, the cost of code complexity, based on the hourly rate of a senior developer, by far outweights the cost of server hardware.
Donate
