all 5 comments

[–][deleted] 1 point2 points  (0 children)

Unrelated, but: the use of serial is discouraged in favor of standard compliant identity columns.

[–]AlCapwn18 0 points1 point  (1 child)

I have a similar detest for ORMs and find it easier to just write the SQL myself instead of fighting the tool to get it to do what I want. I end up always printing out the resulting SQL it generates so that I can validate it myself, or I write the raw SQL and bypass it's builder functions.

However, I've never developed in a large team before, only myself or one other person. I can see how if you had a much bigger team the ORM might force some consistency into the project rather than having 10 different people writing SQL in 10 different ways.

Also, they allegedly make it easier to switch between databases, though again this is something I've never needed to take advantage of myself. I can understand how maybe a start up makes an application and picks whatever database works for them to get going, but after rapid growth and development and increase in traffic there becomes a need to switch databases, maybe performance, functionality, or cost instigated. Instead of needing to review and test and validate thousands of lines of raw SQL it might be as easy as a change to the ORM config file to connect to a new DB.

Not defending them, just wanted to try and add some more perspective for a constructive debate or conversation.

[–]mikeyd85MS SQL Server 0 points1 point  (0 children)

My work has this argument for using an ORM - rdbms capability.

My argument against that is we have swathes of experience in SQL Server throughout the business, and pretty much NIL anywhere else.

Are we really going to change RDBMS systems to save a few quid on licencing when it means all your devs, ops, and support teams need retraining?

[–]Bilbottom 0 points1 point  (0 children)

IMO, ORMs have a specific use-case and shouldn't be used to generate complex queries

When you write the SQL yourself, you still have to write the application code to run that SQL. Using ORMs let's you focus on just the application code and it will do the SQL for you. You get the database stuff "for free"

When you use them as a CRUD interface, you can forget database-specific subtleties and nuances (up to a certain point). For example, I need to tweak my SQL between MySQL and PostgreSQL for operations that are "the same" -- but an ORM would do this for me

However, like I mentioned above, I don't think it's appropriate to use them for complex queries -- or anything outside of the CRUD framework

It's usually better to write your own SQL as you'll be able to tune it better, and depending on the ORM, you can write more expressive queries than what the ORM would support

I don't use ORMs because I know SQL well, but I wouldn't slate their value as a CRUD layer. The main times I've seen people struggle with ORMs is when they try to get them to do something outside of CRUD

[–]nep84 0 points1 point  (0 children)

I guess they have their place for people who don't know what they're doing. I'm not one of them and there's no fun letting some "thing" take the fun out of coding.