Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should learn SQL

executeprogram.com

Post reply on HN
Print view View original

61–70 of 137 posts

Re: Why you should learn SQL

#61

Post by NorwegianDude »

helsinkiandrew wrote: post #24

> The SQL langauge is old, strange, and important. I've always found it strange that something hasn't replace SQL, particularly for traditional 'web' client/server applications. But SQL is probably the only technology/language that has survived in the past 30 years of my career. 99% of their SQL databases probably don't require transactions and ACID behaviour. There nearly always needs to be a layer to convert the ro…

I'd say that if you think transactions is needed just in 0.1 % of usecases then you probably have a lot of bugs in your application, or you have a very simple one.

Transactions are used quite often, and there isn't really any other options.

Re: Why you should learn SQL

#62

Post by BulgarianIdiot »

frogcoder wrote: post #54

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…

> Writing another language in the language I am coding is wrong

That's not what's wrong. But rather writing in some language within a string literal is what feels wrong to you.

With better integration it'd be natural. The problem is, of course, there's no single SQL dialect.

Re: Why you should learn SQL

#63

Post by Akronymus »

urthor wrote: post #49
Akronymus wrote: post #12

Earlier quoted context omitted.

And even if you don't want to normalize, at least don't make the DB basically incomprehensible. Speaking from experience, a "abnormalized" db sucks. https://news.ycombinator.com/item?id=27842820

There's reasons for one wide table. The traditional SQL database uses row based data structures. When you shift to columnar data formats for the table, parquet or any columnar DB, the normalization rules which were developed for row based become extremely different. The brave new world now is in-memory DBs. All those 1970s rules, which make sense for row based tables stored on disk, don't apply to data in RAM. At all…

> There's reasons for one wide table.

There are indeed. It should still be a conscious decision. For the DB I work with, it wasn't.

Re: Why you should learn SQL

#64

Post by BulgarianIdiot »

cratermoon wrote: post #23

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 think about it is hilarious admission of defeat.

SQL is exceptionally good at being a relational algebra language, and if you think in terms of relational algebra, you might find out there's nothing wrong with it, aside from superficial remarks like "FROM should come before SELECT".

Re: Why you should learn SQL

#65

Post by ivolimmen »

holoduke wrote: post #15

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…

I detest hibernate and the whole JPA that came after it. It's more complex than using SQL directly. The whole mapping thing looks simple enough but when I create a one to many relationship on a new project from scratch I always need to reread the documentation because it is not working the way I expected it to work. The reason hibernate was created was to simplify data access. Sorry but I think it failed miserably. On personal projects I use SQL directly. It's easy, fast and simple.

Re: Why you should learn SQL

#66

Post by scns »

SilverRed wrote: post #44
nesarkvechnep wrote: post #40

Earlier quoted context omitted.

Maybe create foreign keys and indexes in your Rails migrations

I had a crazy case where after adding indexes to things, queries suddenly become much much slower. I had to look over the plan and realized that removing these indexes made queries fast again. Turns out you can't just take for granted that an index will speed things up and its something you actually have to test and record before/after results. I'm still slightly at a loss as to what the issue was but the best I can…

Thank you for sharing, something to remember, a valuable lesson.

Re: Why you should learn SQL

#67

Post by tanin »

Pamar wrote: post #13
tanin wrote: post #3

I've built a desktop app that enables you to load CSV files and perform SQL on the CSVs. I imagine it would be handy for anyone who starts learning SQL because you don't need to setup the database or use command-line. If you are interested, please try it out: https://superintendent.app

It's nice. Windows only? (I mostly use a Mac at home). EDIT: no, it's Win/Mac/Linux, apologies...

Yes, it supports all 3 platforms. Hope you enjoy it!

Re: Why you should learn SQL

#68

Post by wvenable »

cratermoon wrote: post #23

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

SQL may look ugly but it got the fundamentals correct.

It's sort of like Git in that way.

SQL is hard to replace because most replacements are either not radical enough to make migration worth it or so radical that it's something else entirely.

Re: Why you should learn SQL

#69

Post by helsinkiandrew »

NorwegianDude wrote: post #61
helsinkiandrew wrote: post #24

> The SQL langauge is old, strange, and important. I've always found it strange that something hasn't replace SQL, particularly for traditional 'web' client/server applications. But SQL is probably the only technology/language that has survived in the past 30 years of my career. 99% of their SQL databases probably don't require transactions and ACID behaviour. There nearly always needs to be a layer to convert the ro…

I'd say that if you think transactions is needed just in 0.1 % of usecases then you probably have a lot of bugs in your application, or you have a very simple one. Transactions are used quite often, and there isn't really any other options.

My apps may be simple and have lots of bugs but I'd still say that the vast majority of SQL calls in all apps are to read data that isn't being written to at all or very infrequently - hours/days/weeks and reading possibly temporally inconsistent data isn't important.

Re: Why you should learn SQL

#70

Post by elmo2you »

holoduke wrote: post #15

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…

I think you are complete right, but maybe I believe so in part because of my age.

To me the general undertone in all the arguments I have heard over time is either "we now have this tools/service solving that us" or "why would I need to learn all this (complicated) stuff, I've done fine without it".

The first variant I just never have seen being true, but that might be hard to see by someone who is reluctant to learn/understand anything about relational data organization.

The second variant I can to some degree sympathize with, because it does seems daunting to me, how much time/effort the young kids these days have to spend on keeping up with the ever changing landscape of new smoke and mirrors technology (very little of it fundamentally new or innovative). Learning something that appears to be far removed from the tools they already know will no doubt feel like a challenge and maybe therefore also as a waste of time.

However, the apparent resistance to learn about something as relational data organization (because this is actually about far more than just SQL), feels to me as rather troubling regarding the quality of software design.

The way I've hears some people talk about SQL and relational data organization, made me even wonder if they should even be allowed to call themselves software engineers. To me they sounded like architects telling me that concrete is such an outdated and unstructured mess that they no longer need (to know about) it to design buildings.

The problem is, buildings and software will be build anyways (for there is a need) .. and if their architects can get away with saying they don't need to know about some fundamental theory, then good luck with the quality of that software. No amount of tools/services that supposedly abstract the challenges of good structured data design away, can ever solve that problem.

Post reply on HN