Hacker News Reader

Comment by marktangotango | Hacker News Reader

Imo every developer should be comfortable with sql, upto joins at least. Basic data modelling is also invaluable.

Serious question...what kind of developer can you be without knowing SQL?

One who does lots of low-level C/Assembly programming. I know several people who do lots of low-level OS work, and don't use SQL.

I was a developer for >3 years at my last job, and barely touched SQL. I did desktop software that mostly interacted with streaming data, state machines, etc, and mostly wrote limited data to flat files as text or XML where necessary. We just didn't do anything where database storage was appropriate. I worked with a few SELECT queries to get data from a legacy Access DB, but that's about it. I was probably barely at lesson 1 level on all of the linked lessons.

I have learned a lot of SQL at my current job, though. I can now admin multiple types of DB servers and write SQL up through window queries, CTEs, indexes, stored procedures, etc, so I've learned enough to be past the end of every SQL lesson I've ever seen. There's a huge amount of fascinating stuff to learn and a ton of cool stuff you can do.

Web developers don't have to know SQL if they are only doing front end work, since the routes they hit which may or may not use SQL are written by back end developers.

Actually I'm a back end developer and I don't use SQL at all. I learned it (a bit at least) on my own just out of interest and random personal projects, but I don't use SQL at work at all; we only use DynamoDB.

Game engines, graphics, animations, lot of front-end web stuff... The list goes on.

Not that I hadn't already done plenty of CRUD in SQL in jobs prior, but for 4 years I worked on streaming stock quote servers. All in all the system had 500+ servers deployed in a tiered setup. No data was persisted to disk (save for some config), and no SQL was ever involved. Ticker symbols (CUSIPs) did need to be looked up and those went through our network, but the actual lookups went out to a service, and results were cached.

That's just one example. I'm sure there are many.

I write mathematical optimization software. I haven't used SQL since my undergrad. I know that one of our teams though use SQLite to store benchmarking results or something.

I've been programming professionally for 6 years and only just started using SQL for the first time for a side project -- some web dev stuff.

I know Prolog pretty well so it's not like I was completely flabbergasted by it, I just had no need to use SQL before.

Big Data Developers can use Spark, Cascdading or Pig to do pretty advanced data warehouse, analytics, ETL tasks. Web app developers accessing databases can use an ORM e.g. Hibernate to abstract away the SQL layer or use JSON to query MongoDB, CouchDB etc.

You could write every application under the sun without knowing a single bit of SQL.

One can't seriously use an ORM without knowing SQL, because they all come with their own proprietary incomplete wrapper language (HQL, etc.). ORM simplicity breaks down the moment you push them even slightly hard.

Big data analytics is increasingly done with Hive's SQL dialect, or Impala, or Hawq. Beyond all of these, relational data modelling is an essential skill for anyone building server side applications if you have to deal with information management, whether you use SQL or not.

In today's world you could probably be powerful using the NoSQL databases. But, imho, you will still have to understand the basics of set theory. Unions, intersects, etc.

But I agree with the spirit of what you're saying. A good programmer will know SQL. It's definitely not going away anytime soon.

SQL has almost no practical overlap with set theory. Relational calculus, and relational algebra, sure, but SQL neither operates on nor produces sets.

SELECT column_1 FROM Strings_1 UNION SELECT column_1 FROM Strings_2

Is this set theory? A UNION of two sets? Oh I see your pedantic argument. They aren't sets because they are ordered, they are lists.

If I can't explain how UNIONS and INTERSECTS are relevant to SQL to you then I can't help you because you're simply being difficult. It has every practical application to SQL.

    > They aren't sets because they are ordered, they are
    > lists.

Half correct - the other reason the results aren't sets are because they are also able to return duplicates, as evidenced by UNION ALL and INTERSECT ALL.

Were I being pedantic, I would turn to the (horrifyingly inconsistently written) SQL1992 standard, which explicitly says that your columnar inputs are multisets (which is a posh way of saying "not a set").

Coming back to your original assertion:

    >> you will still have to understand the basics of set
    >> theory. Unions, intersects

In 15 years of software development, open-source and commercial, mostly with databases, I've only used UNION, INTERSECT, and EXCEPT in SQL when doing academic homework, translating from relational algebra and relational calculus. I note the world's most popular open-source database doesn't support INTERSECT.

But most people don't write SQL by hand any more, they use an ORM - most of which have scant support for UNION, INTERSECT, and EXCEPT, because they are obvious vestigial details left over from archaic database theory. I have resisted the temptation to become actually pedantic by discussing the SQL treatment of NULLs.

This constitutes "almost no practical overlap".

But look, here's the meat: Fundamentally, sets are distinguished from other list-like data types by having no ordering, and having no repetition. Practical SQL usage requires you to understand that you will have duplicates, that you may well need to aggregate those duplicates somehow, and that order matters.

That's a nicely crafted response. Allow me to retort: http://lmgtfy.com/?q=set+theory+and+sql

Huh, I guess others think like I do.. I guess we're all morons. Shrugs.

    > Huh, I guess others think like I do..

There is absolutely no safety in numbers:

http://lmgtfy.com/?q=columbus+discovered+america

http://lmgtfy.com/?q=aspartame+dangerous

http://lmgtfy.com/?q=indigo+children

    > I guess we're all morons

Maybe, but it's more likely you're just wrong.

I'm not exactly sure why you're so opposed to the idea, but okay. You've won. I will never ever say SQL relates to sets. Thanks!

I've used intersections and unions with sql. And also Cartesian products (a cross join). Don't those count?

No, because in both cases the inputs and outputs are lists, not sets.

Mobile developer who uses existing APIs ?

You could develop relational database applications using Dataphor's D4 language without knowing SQL, though I suspect most D4 users also know SQL.

Or you could develop software that doesn't use relational databases for persistence; there's still lots of that.

As a game developer, I have a bunch of very talented programmers in my office, and afaik I know the most SQL in the office, which isn't much.

Embedded? D3? COBOL?

Yup - very few of our graphics required any SQL

http://www.bloomberg.com/topics/graphics

They exist, they really exist!

Reply on news.ycombinator.com