Which databases you mainly worked with?
Why you prefer one over other?
Example of when you used one over the other – applications you used for each and Why?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Prisma error: Environmental variable not found: DATABASE_URL
Abdullah Bashir -
Why Cookie-Less is the Future for Tracking Analytics in Europe (and the World)
Antonio | CEO at Litlyx.com -
The hidden cost of code reviews
Marco Patiño López -
What is RemoteWLB?
RemoteWLB -
Top comments (5)
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.
Mostly worked with SQL databases. Used a bit of MongoDB and Firebase. But SQL would be my go-to database in all cases. My philosophy for a database is, "choose your database based on how your data looks, not based on what features the database offers". Because I have seen too many people jumping to Firebase for its "Realtime" features.
Over the years I've been working a lot with relational databases. Mainly Microsoft SQL Server, but I did a few projects with Oracle and one or two with MySql, and more than a few with MS-Access back in the day.
Over the course of the last year I became acquainted with MongoDb.
I think both relational databases and NoSql databases has their strengths and weaknesses - but my go-to database would definitely be SQL Server, since I have the most experience with it and things I can easily do with it might take much more time and effort on other databases.