4 ms·

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

by marktangotango 11y ago

pcurve 11y ago
Serious question...what kind of developer can you be without knowing SQL?
- havetoregister 11y ago
  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.
- rifung 11y ago
  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.
- theoduino 11y ago
  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.
- optimusclimb 11y ago
  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.
- enraged_camel 11y ago
  Game engines, graphics, animations, lot of front-end web stuff... The list goes on.
- dragonwriter 11y ago
  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.
- cdcarter 11y ago
  Embedded? D3? COBOL?
  - 1wheel 11y ago
    Yup - very few of our graphics required any SQL http://www.bloomberg.com/topics/graphics http://www.bloomberg.com/topics/graphics
- ianstallings 11y ago
  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.
  - peteretep 11y ago
    SQL has almost no practical overlap with set theory. Relational calculus, and relational algebra, sure, but SQL neither operates on nor produces sets.
    - schrodinger 11y ago
      I've used intersections and unions with sql. And also Cartesian products (a cross join). Don't those count?
      - peteretep 11y ago
        No, because in both cases the inputs and outputs are lists, not sets.
    - ianstallings 11y ago
      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.
      - peteretep 11y ago
        > 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.
- perfectstorm 11y ago
  Mobile developer who uses existing APIs ?
- Blackthorn 11y ago
  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.
- ufmace 11y ago
  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.
- ryan-allen 11y ago
  They exist, they really exist!
- threeseed 11y ago
  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.
  - parasubvert 11y ago
    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.
- Arelius 11y ago
  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.

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

pcurve 11y ago

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

havetoregister 11y ago
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.
rifung 11y ago
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.
theoduino 11y ago
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.
optimusclimb 11y ago
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.
enraged_camel 11y ago
Game engines, graphics, animations, lot of front-end web stuff... The list goes on.
dragonwriter 11y ago
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.
cdcarter 11y ago
Embedded? D3? COBOL?
- 1wheel 11y ago
  Yup - very few of our graphics required any SQL http://www.bloomberg.com/topics/graphics http://www.bloomberg.com/topics/graphics
ianstallings 11y ago
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.
- peteretep 11y ago
  SQL has almost no practical overlap with set theory. Relational calculus, and relational algebra, sure, but SQL neither operates on nor produces sets.
  - schrodinger 11y ago
    I've used intersections and unions with sql. And also Cartesian products (a cross join). Don't those count?
    - peteretep 11y ago
      No, because in both cases the inputs and outputs are lists, not sets.
  - ianstallings 11y ago
    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.
    - peteretep 11y ago
      > 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.
perfectstorm 11y ago
Mobile developer who uses existing APIs ?
Blackthorn 11y ago
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.
ufmace 11y ago
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.
ryan-allen 11y ago
They exist, they really exist!
threeseed 11y ago
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.
- parasubvert 11y ago
  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.
Arelius 11y ago
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.