I've been working and studying DBMS tech since the very beginning of IT, and to me SQL is a work of mathematical beauty and every serious developer must learn it inside out.
I also believe the pendulum is swinging back to pure SQL vs. noSQL (MongoDB, Firebase, Couch) for many use cases. With RDS at Amazon being so easy and fast, you can have an enterprise-grade MySQL or Postgres instance up in about 2 min.
This issue is that SQL gets very detailed and complicated when you combine related objects. This is why Object-Relational-Management (ORM) helpers have arrived to let programmers obfuscate the complexity of SQL in order to speed up development time quite a bit.
Personally, I am decidedly anti-ORM because I know how to deal with SQL using a personal set of tools, but I can definitely see how front end developers need ORM in order to make any progress.
That is where I see the challenge today. To ORM or not to ORM, that is the question!
ORM vs no ORM is an interesting debate that seems to come up quite a bit. I'm in the ORM camp myself, but not because I don't want to know the details of what's happening behind the scenes. In fact, I think learning an ORM when you don't know SQL first is putting a real handicap on yourself.
But despite knowing SQL pretty well, I wouldn't want to build an application without an ORM. There are many pain points without it, but in the interest of not turning this into a full on blog post, I think managing relationships is one of the biggest.
It's just very nice to be able to load an object, and say artist.songs or song.artist or even song.artist.label.
What I'd like to know is what the middle-ground alternatives are, somewhere between having strings of SQL everywhere and using a full-blown ORM.
I get it. Not using an ORM for a front-end app would suck. So, my ORM "Eye of Sauron" will not gaze upon web technology devs.
However, using an ORM when you are building a REST API or a big database, is a mistake in my view. You need to really figure out your objects and normalize them into a one SQL table at a time.
The way I deal with all the cruft SQL needs is to have a bunch of "factory" tools that will generate my SQL schemas and language bindings. Surprisingly, my go-to tool has been Excel of all things. I keep each object in its own sheet, and then use text-generating formulae to spit out Swagger definitions, Go structs, Java Classes, or whatever.
In the case of Go SQL, I stick all this generated stuff into Go functions and then "compile" my SQL statements into "prepared statements". Then I wrap all that stuff with some nice clean function calls like account := getAccount(accountID). I've done the same thing in Java and PHP.
If you are building a backend, then I think you need to pay attention to all the marshalling, unmarshalling, type conversions, and object aggregation that ORMs smooth over for front-end developers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been working and studying DBMS tech since the very beginning of IT, and to me SQL is a work of mathematical beauty and every serious developer must learn it inside out.
I also believe the pendulum is swinging back to pure SQL vs. noSQL (MongoDB, Firebase, Couch) for many use cases. With RDS at Amazon being so easy and fast, you can have an enterprise-grade MySQL or Postgres instance up in about 2 min.
This issue is that SQL gets very detailed and complicated when you combine related objects. This is why Object-Relational-Management (ORM) helpers have arrived to let programmers obfuscate the complexity of SQL in order to speed up development time quite a bit.
Personally, I am decidedly anti-ORM because I know how to deal with SQL using a personal set of tools, but I can definitely see how front end developers need ORM in order to make any progress.
That is where I see the challenge today. To ORM or not to ORM, that is the question!
ORM vs no ORM is an interesting debate that seems to come up quite a bit. I'm in the ORM camp myself, but not because I don't want to know the details of what's happening behind the scenes. In fact, I think learning an ORM when you don't know SQL first is putting a real handicap on yourself.
But despite knowing SQL pretty well, I wouldn't want to build an application without an ORM. There are many pain points without it, but in the interest of not turning this into a full on blog post, I think managing relationships is one of the biggest.
It's just very nice to be able to load an object, and say artist.songs or song.artist or even song.artist.label.
What I'd like to know is what the middle-ground alternatives are, somewhere between having strings of SQL everywhere and using a full-blown ORM.
I get it. Not using an ORM for a front-end app would suck. So, my ORM "Eye of Sauron" will not gaze upon web technology devs.
However, using an ORM when you are building a REST API or a big database, is a mistake in my view. You need to really figure out your objects and normalize them into a one SQL table at a time.
The way I deal with all the cruft SQL needs is to have a bunch of "factory" tools that will generate my SQL schemas and language bindings. Surprisingly, my go-to tool has been Excel of all things. I keep each object in its own sheet, and then use text-generating formulae to spit out Swagger definitions, Go structs, Java Classes, or whatever.
In the case of Go SQL, I stick all this generated stuff into Go functions and then "compile" my SQL statements into "prepared statements". Then I wrap all that stuff with some nice clean function calls like account := getAccount(accountID). I've done the same thing in Java and PHP.
If you are building a backend, then I think you need to pay attention to all the marshalling, unmarshalling, type conversions, and object aggregation that ORMs smooth over for front-end developers.