5 ms·

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

by 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
        You're going to get a huge reduction in code for all sorts of things, especially when navigating multiple relations, grouping, sub-selects, etc.. var results = db.myTable .where(x => x.value > 6) .where(mySpecialConditionalLogicFunction) .select(x => { thing = x.relation.relation.relation.value, thingList2 = x.relation.relations .groupby(y => y.value) .select(g => g.count) .orderby(y => y.value) .take(5), thing3 = x.relations .where(z => z.relation1.value < z.relation2.value) .select(z => z.relation.value) .max(), thing4 = myReusableSelectDTOfunction, etc.. The sql for this would be very dense, hard to read/maintain. Especially when building structured objects, grouping, filtering etc.. Those composable sub-select functions often build common dtos which ensure the same structured data is sent regardless of the api. And if the dto is updated, all queries inherit it automatically.
        yrgulation 4y ago
        This brings fond memories of my early stages where i became fond of the method chaining pattern. I became fascinated by it when using doctrine. However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems. The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code. Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.
stavros 4y ago
They're a convenience for 99.9% of use cases. For the other 0.1%, I write SQL, but to be honest, I've never had to yet. You can deliver business value with boring glue code.
- xd 4y ago
  So you have 0.1% SQL skill .. work on it.
  - stavros 4y ago
    Actually a flat 0%.
    - yrgulation 4y ago
      Well, that the issue with php devs.
      - stavros 4y ago
        Oh I don't know any PHP, sadly. That's probably another issue with us.
        yrgulation 4y ago
        You think you did a funny but you’d be surprised how many php devs dont know php.
        stavros 4y ago
        Oh, all of them.
        yrgulation 4y ago
        There is merit in this - once a php dev does get to know the language they move away to other languages. So you are indeed left with people that dont know the language.

by xd 4y ago

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
      You're going to get a huge reduction in code for all sorts of things, especially when navigating multiple relations, grouping, sub-selects, etc.. var results = db.myTable .where(x => x.value > 6) .where(mySpecialConditionalLogicFunction) .select(x => { thing = x.relation.relation.relation.value, thingList2 = x.relation.relations .groupby(y => y.value) .select(g => g.count) .orderby(y => y.value) .take(5), thing3 = x.relations .where(z => z.relation1.value < z.relation2.value) .select(z => z.relation.value) .max(), thing4 = myReusableSelectDTOfunction, etc.. The sql for this would be very dense, hard to read/maintain. Especially when building structured objects, grouping, filtering etc.. Those composable sub-select functions often build common dtos which ensure the same structured data is sent regardless of the api. And if the dto is updated, all queries inherit it automatically.
      - yrgulation 4y ago
        This brings fond memories of my early stages where i became fond of the method chaining pattern. I became fascinated by it when using doctrine. However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems. The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code. Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.

stavros 4y ago

They're a convenience for 99.9% of use cases. For the other 0.1%, I write SQL, but to be honest, I've never had to yet. You can deliver business value with boring glue code.

xd 4y ago
So you have 0.1% SQL skill .. work on it.
- stavros 4y ago
  Actually a flat 0%.
  - yrgulation 4y ago
    Well, that the issue with php devs.
    - stavros 4y ago
      Oh I don't know any PHP, sadly. That's probably another issue with us.
      - yrgulation 4y ago
        You think you did a funny but you’d be surprised how many php devs dont know php.
        stavros 4y ago
        Oh, all of them.
        yrgulation 4y ago
        There is merit in this - once a php dev does get to know the language they move away to other languages. So you are indeed left with people that dont know the language.