Live data from Hacker News

Why you should learn SQL

executeprogram.com

71–80 of 137 posts

Re: Why you should learn SQL

#71

Earlier quoted context omitted.

Yeah one should know why it’s important to normalize, and then when they go a different path, it is done consciously and not because they are inexperienced and didn’t really know any better. Folks out there who don’t want to learn the ins and outs of database theory - please don’t; read up on it, it’s a very important skill & knowledge to have and doesn’t take long to master. It does take a few days, perhaps weeks, f…

For Databases, it takes me a concious effort to not go to at least 3rd NF. Except for addresses/names/telephone numbers, I have been burned by ANY assumption I made. Those, I tend to just store as something like char(255) nowadays by default, unless business requirements force me to split it up, but even then, after voicing my concerns. Edit: reading up on the addresses falsehoods again, 255 may not be enough. https:…

If you use Postgres or SQLite, TEXT is preferable for strings.

Re: Why you should learn SQL

#72

I used to love ORM, I used it everywhere. Writing another language in the language I am coding is wrong. ORM simplifies my programs. No, ORM does not simplify coding! It's a big complex adapter which does not fit many cases. RDBM itself is complex enough, let's put another complex abstraction above it so we can forget about the tables and columns and joins and foreign keys. Complexity added upon another complexity do…

If you use IntelliJ IDE in their commercial version (at least of PyCharm) they integrated DataGrip. Basically if you connect to your database and give an option to fetch your schema the IDE starts scanning for strings and if it detects SQL it provides IDE features to it as well (like auto completion, and some refactoring etc).

I think ORM and query builders were trying to hack around to make IDEs understand SQL, when in reality this approach is what actually was needed.

Re: Why you should learn SQL

#74

Earlier quoted context omitted.

He said better than SQL.

To me, ORM code is better than raw SQL. But, a lot many applications can be developed without really knowing the depths of SQL with help of the ORM itself.

Is it? All that's ever worked for me with ORMs are simple CRUD apps that don't require referential integrity. We currently need to support one built on Django/ORM where this isn't the case and e.g. deleting an object can require deleting thousands of others.... which the ORM helpfully renders into thousands of queries and can take you half an hour. Luckily the creators soon decided to switch off all timeouts....

Re: Why you should learn SQL

#75

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

The monkey's paw - you get your wish, but now instead of one annoying query language, you have two!

Re: Why you should learn SQL

#76
post #71

Earlier quoted context omitted.

For Databases, it takes me a concious effort to not go to at least 3rd NF. Except for addresses/names/telephone numbers, I have been burned by ANY assumption I made. Those, I tend to just store as something like char(255) nowadays by default, unless business requirements force me to split it up, but even then, after voicing my concerns. Edit: reading up on the addresses falsehoods again, 255 may not be enough. https:…

If you use Postgres or SQLite, TEXT is preferable for strings.

I just wanted to give a easily understood example. Specifically to point out that even limiting the length can make problems.

Re: Why you should learn SQL

#78
post #72

I used to love ORM, I used it everywhere. Writing another language in the language I am coding is wrong. ORM simplifies my programs. No, ORM does not simplify coding! It's a big complex adapter which does not fit many cases. RDBM itself is complex enough, let's put another complex abstraction above it so we can forget about the tables and columns and joins and foreign keys. Complexity added upon another complexity do…

If you use IntelliJ IDE in their commercial version (at least of PyCharm) they integrated DataGrip. Basically if you connect to your database and give an option to fetch your schema the IDE starts scanning for strings and if it detects SQL it provides IDE features to it as well (like auto completion, and some refactoring etc). I think ORM and query builders were trying to hack around to make IDEs understand SQL, when…

No, ORM provides an inspectable central entry point for your models with a standardized API. That's the feature.

That's why you get a great django ecosystem: the ORM abstractions allow all libs to rely on the fact the rest of the code access the model the same way.

Re: Why you should learn SQL

#79

I am using spring hibernate. It's so powerful. I don't need to write and understand SQL anymore. Sarcasm off: I see more and more juniors without SQL skills. Various reasons they give me. From the nosql plague to some cloud solutions to the above example. SQL seems to be not so fun anymore. I have a hard time understanding that. Since data storage is such a fundamental part of your application. I would even argue tha…

SQL is useful but we’ve spent decades to abstract it away, because the Java/SQL articulation is always circumvoluted, and juniors do without. Then they load two tables in Java and join them manually in memory; or they fetch the principal record, and use the getter to retrieve the dependency, so Hibernate does one query per row. I accuse all ORMs, especially Hibernate, of making it too easy to skip SQL, and I accuse J…

If you are able to use Kotlin, you can write multiline strings.

Re: Why you should learn SQL

#80

I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. It's like FORTRAN, except FORTRAN has had the decency to stay in use where it's really the best choice. But SQL is out there, like Clippy. "Hey, I see you're collecting some data. SELECT TRUE FROM HELP WHERE COLLECTING_DATA IS TRUE

> I've spent most of my career hoping that something - anything that's better than SQL will come along and replace it. So, if we put aside Clippy jokes and so on, what's your problem with SQL exactly and what does "better than SQL" mean to you? Because what I saw in the last couple of decades is the NoSQL movement lose air, and half the products representing it adding some sort of SQL dialect support, which if you th…

It's super verbose, doesn't compose well with the host language primitives, is hard to introspect, full of gotchas and very low level.
Post reply on HN