6 ms·

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

by xd 4y ago

yrgulation 4y ago
But “what if we switch to a different database engine”? Yet i’ve never seen that happen! Edit: wait smarty still a thing!?
- xd 4y ago
  I used Postgres when I first started out in ~2002 but it was slow, really slow, I switched to MySQL and it was fast and the customers happy. The MyISAM table engine was shit hot(fast) but it took me years to get my head around constraints and then indexes etc to actually get a basic level of competence and realise MyISAM was a bunch of trade off's for performance. Anyway I loved PG and still do romanise it.. what if I stayed.. what could have been.. but it didn't get the job done, for me. Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.
bottlepalm 4y ago
This point of view is a fallacy itself. ORMs are about productivity and maintainability. Some of us write enterprise applications where ORMs are a godsend. They're not a replacement for being knowledgeable in SQL whatsoever.
- xd 4y ago
  It's just my opinion based on 20+ years of developing data management solutions across thousands of customers.. any framework employs a set of beliefs and that creates a box you are constrained to think in, hell SQL is one of them boxes. You say "They're not a replacement for being knowledgeable in SQL whatsoever." .. so what are they then? Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.
  - bottlepalm 4y ago
    Not sure if you've used Entity Framework, but you can do compos (with logic) amazing complex queries with relatively little code in a way that is statically typed and super easy to maintain. I'm talking about pulling heavily structured data from the database without having to pull from flat tables and structure it yourself server side. Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc.. We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.
    - yrgulation 4y ago
      But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.
      - bottlepalm 4y ago
        The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries. Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs. I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM. I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.
        xd 4y ago
        Can you show me an example of the 10x less code?
        bottlepalm 4y ago
samhuk 4y ago
I will be bias here as I made my own ORM (for typescript and postgre, no less), but I have to hard disagree. As other comments have pointed out, ORMs are about productivity, getting persistence done quickly. Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand? Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic. Few more points, but I think the drift is caught.
- yrgulation 4y ago
  “ Also, it doesn't have to be black and white - ORM or no ORM The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

by xd 4y ago

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

yrgulation 4y ago

But “what if we switch to a different database engine”? Yet i’ve never seen that happen! Edit: wait smarty still a thing!?

xd 4y ago
I used Postgres when I first started out in ~2002 but it was slow, really slow, I switched to MySQL and it was fast and the customers happy. The MyISAM table engine was shit hot(fast) but it took me years to get my head around constraints and then indexes etc to actually get a basic level of competence and realise MyISAM was a bunch of trade off's for performance. Anyway I loved PG and still do romanise it.. what if I stayed.. what could have been.. but it didn't get the job done, for me. Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.

bottlepalm 4y ago

This point of view is a fallacy itself. ORMs are about productivity and maintainability. Some of us write enterprise applications where ORMs are a godsend. They're not a replacement for being knowledgeable in SQL whatsoever.

xd 4y ago
It's just my opinion based on 20+ years of developing data management solutions across thousands of customers.. any framework employs a set of beliefs and that creates a box you are constrained to think in, hell SQL is one of them boxes. You say "They're not a replacement for being knowledgeable in SQL whatsoever." .. so what are they then? Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.
- bottlepalm 4y ago
  Not sure if you've used Entity Framework, but you can do compos (with logic) amazing complex queries with relatively little code in a way that is statically typed and super easy to maintain. I'm talking about pulling heavily structured data from the database without having to pull from flat tables and structure it yourself server side. Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc.. We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.
  - yrgulation 4y ago
    But you can already write amazingly complex queries in sql, and structure them as objects directly using pdo. If there are hundreds of developers working against the same codebase then that codebase is too large. If you need to query hundreds of tables in one go you need to consider denormalisation or using a document storage.
    - bottlepalm 4y ago
      The ORM code will be 10x smaller than the generated SQL, especially for structured data and composing queries. Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs. I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM. I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.
      - xd 4y ago
        Can you show me an example of the 10x less code?
        bottlepalm 4y ago

samhuk 4y ago

I will be bias here as I made my own ORM (for typescript and postgre, no less), but I have to hard disagree. As other comments have pointed out, ORMs are about productivity, getting persistence done quickly. Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand? Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic. Few more points, but I think the drift is caught.

yrgulation 4y ago
“ Also, it doesn't have to be black and white - ORM or no ORM The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.