SQL? What is it and why is it important?
closed account (2LzbRXSz)
Alright, I know I could Google this, and I plan on doing a little research after posting this. I'm just a fan of forum communication, because talking with others just feels more human and is quite informative.
I also know this'll sound really ignorant, but why is SQL required for so many jobs? What is it's purpose, and should I learn it (other than so I can get a job)? Is it worth knowing? Does it come in handy?
I also know this'll sound really ignorant, but why is SQL required for so many jobs? What is it's purpose, and should I learn it (other than so I can get a job)? Is it worth knowing? Does it come in handy?
SQL is a database language.
A database is effectively like a humongous group of spreadsheets (aka "tables") with tons and tons and tons of data. With SQL you make "queries" to get/set data in the database.
Pretty much everything runs on databases. Any site or company that has a large amount of information to store (Read: every company, which is why it's a high demand for jobs) probably uses a database to store it.
These forums, for example. Things like the user list is probably stored in a table, with the actual posts being in another table in the same database.
If you work with databases, yes. =P
It doesn't sound like you do very often, though.
Neither do I. My SQL is hella rusty.
A database is effectively like a humongous group of spreadsheets (aka "tables") with tons and tons and tons of data. With SQL you make "queries" to get/set data in the database.
Pretty much everything runs on databases. Any site or company that has a large amount of information to store (Read: every company, which is why it's a high demand for jobs) probably uses a database to store it.
These forums, for example. Things like the user list is probably stored in a table, with the actual posts being in another table in the same database.
| and should I learn it (other than so I can get a job)? Is it worth knowing? Does it come in handy? |
If you work with databases, yes. =P
It doesn't sound like you do very often, though.
Neither do I. My SQL is hella rusty.
Last edited on
can it be called a sub-type of c++? Is it easier than c++ or difficult?
~We will learn sql next semester in school. Just excited :D
~We will learn sql next semester in school. Just excited :D
C++ is a programming language, while SQL is a query language. They aren't the same thing, so it isn't really meaningful to compare them in general. In my opinion, SQL is easier than C++ as it is simpler, but I'd say what matters more is the complexity of the task (e.g., you can have a simple C++ programming assignment or an extraordinarily complex query).
closed account (2LzbRXSz)
Thank you guys, these were all really helpful answers! I took a briefly skimmed over some tutorials for it, and the syntax looks really clean. Sort of reminds me of Ruby. Even if I haven't worked with databases yet, I think I might learn it when I get the chance just because of how clear it looks.
What's the difference between the different types of SQL? Is it like the relationship between Javascript and JQuery, or...?
What's the difference between the different types of SQL? Is it like the relationship between Javascript and JQuery, or...?
closed account (Gvp9LyTq)
In one sense there is no SQL it is just an abstract idea.
If I take your question literally and assume no misunderstanding the answer is there are different ISO SQL standards just like there are different C++ ISO standards.
But I think there might be an additional misunderstanding. Of the relational database engines I am aware of there is not one that is fully compliant with any ISO SQL standard. So when the average person says "do you know SQL" they probably mean "can you write simple SQL queries for the database that we use?"
You should be able to answer the above question as yes. Query languages in general are easy and SQL is very easy at a basic level. Getting performance out of a database is another matter--but if someone asks you "do you know SQL" they probably don't (or at least that has been my experience).
Right now where I live it seems to me that there are plenty of good paying jobs for Database administrators--for programmers not so much. I am told that database administration is very very boring if you are good at it, but the pay is good.
If I take your question literally and assume no misunderstanding the answer is there are different ISO SQL standards just like there are different C++ ISO standards.
But I think there might be an additional misunderstanding. Of the relational database engines I am aware of there is not one that is fully compliant with any ISO SQL standard. So when the average person says "do you know SQL" they probably mean "can you write simple SQL queries for the database that we use?"
You should be able to answer the above question as yes. Query languages in general are easy and SQL is very easy at a basic level. Getting performance out of a database is another matter--but if someone asks you "do you know SQL" they probably don't (or at least that has been my experience).
Right now where I live it seems to me that there are plenty of good paying jobs for Database administrators--for programmers not so much. I am told that database administration is very very boring if you are good at it, but the pay is good.
closed account (2LzbRXSz)
I see, I see.
Thank you for your reply. I think I understand it a little more now. The whole concept is pretty interesting (ironic since database administration is the opposite of interesting).
Thank you for your reply. I think I understand it a little more now. The whole concept is pretty interesting (ironic since database administration is the opposite of interesting).
I'm currently working with AWS DynamoDB which is a"no SQL" database and it's actually quite interesting designing the database formats with that information we'll be using, who will be accessing it and how, what they'll be scanning for in the data, etc... I can't imagine it'll be as fun maintaining it though XD
closed account (2LzbRXSz)
Haha, I thought no sql meant an SQL database without the SQL, but I googled it and apparently it's typically seen as, "not only SQL"
Designing the databases sounds great, but data entry itself sounds a bit mindless. I heard it offers lots of job opportunity though. I wonder how long it'll be until we have some sort of robot that does the data entry for us? Surely that already exists, right??
Designing the databases sounds great, but data entry itself sounds a bit mindless. I heard it offers lots of job opportunity though. I wonder how long it'll be until we have some sort of robot that does the data entry for us? Surely that already exists, right??
Robot?
It'll just be another computer program. At my work we currently just have our main database as a .csv file and just manually add to the bottom of it. I'm going to be developing the database and I can guarantee you I'm not entering all entries manually... I'll just have it load from our offline version at the click of a button (it's someone else's job to update that XD )
It'll just be another computer program. At my work we currently just have our main database as a .csv file and just manually add to the bottom of it. I'm going to be developing the database and I can guarantee you I'm not entering all entries manually... I'll just have it load from our offline version at the click of a button (it's someone else's job to update that XD )
closed account (2LzbRXSz)
Ah, I know it'd just be another program but as the years go on I find myself making more jokes about robots taking over the world.
Gotcha, sounds like a really good system.
Gotcha, sounds like a really good system.
| SatsumaBenji wrote: |
|---|
| At my work we currently just have our main database as a .csv file and just manually add to the bottom of it. |
That was actually painful for me to read. I mean I've heard of this being done and I don't even roll my eyes when I hear people call Excel a DB program anymore. But man this is a terrible idea. I really hope your boss knows how much you're helping him up.
Heh, another forum member had that same issue at his workplace. He was able to migrate it all to a MSSQL server, though. I suggest doing the same.
closed account (Gvp9LyTq)
Here are my opinions:
1.) Excel is never a good choice for a database. Although, it may be a good choice for querying data that is stored in another database.
2.) Text delimited files are often a good choice for the storing of data. Delimited text files are sometimes all that is needed.
3.) A poorly designed database is still a poor database no matter what it is. I have seen beautiful interfaces to professional database engines that were useless because you could not rely on the data that was in it, nor be sure that the data you retrieved from it was complete.
If you are going to create a database take some time to learn some basics about design. People believe that all you need is common sense to create a database, but that is not the case and the design is more important than the database engine that you use. A simple design error can result in problems querying data for years and years.
1.) Excel is never a good choice for a database. Although, it may be a good choice for querying data that is stored in another database.
2.) Text delimited files are often a good choice for the storing of data. Delimited text files are sometimes all that is needed.
3.) A poorly designed database is still a poor database no matter what it is. I have seen beautiful interfaces to professional database engines that were useless because you could not rely on the data that was in it, nor be sure that the data you retrieved from it was complete.
If you are going to create a database take some time to learn some basics about design. People believe that all you need is common sense to create a database, but that is not the case and the design is more important than the database engine that you use. A simple design error can result in problems querying data for years and years.
Last edited on
| genny wrote: |
|---|
| 2.) Text delimited files are often a good choice for the storing of data. Delimited text files are sometimes all that is needed. |
In regards to the sometimes part; I would like to expand on that and state, in my not quite humble opinion, that text delimited files are all that are ever needed. Users should never be allowed to even see the back end of a database much less screw around in it. Therefore there should never be any need for a DB to accommodate stupid crap like pivot tables or cell shading within its file format.
@ Everyone: Not to derail this thread, but what are your guys opinions on XML for I\O? I think I'm starting to appreciate it, but at the same time I can't think of anything I've used which fills the same roll.
Last edited on
You can't think of anything that fills same roll?
How about YAML? (YAML Ain't Markup Language).
Strictly speaking it isn't anywhere near as robust or as foolproof as XML, however I personally don't really like markup languages that much and YAML seems like a great intermediate between a markup and binary.
If used correctly it can still be extensible provided that your program can parse in such a manor, but it does rely on correct whitespace and also breaks on a lot of other format errors where as because XML is marked it can just ignore small sections.
And about my work place databases being csv it's actually probably the best solution for the short term we've been using it. We add massive at most 4 entries per week, someone's no entries for a month, and the database has about 6 fields.
Our most recent version holds a little less than 250 entries...
Our company is still really small and making lots of progress very quickly, we have to prioritise development where it's needed most and just use the simplest solution for other things in the meantime, but we still make sure whatever we do is suitable for what we need
How about YAML? (YAML Ain't Markup Language).
Strictly speaking it isn't anywhere near as robust or as foolproof as XML, however I personally don't really like markup languages that much and YAML seems like a great intermediate between a markup and binary.
If used correctly it can still be extensible provided that your program can parse in such a manor, but it does rely on correct whitespace and also breaks on a lot of other format errors where as because XML is marked it can just ignore small sections.
And about my work place databases being csv it's actually probably the best solution for the short term we've been using it. We add massive at most 4 entries per week, someone's no entries for a month, and the database has about 6 fields.
Our most recent version holds a little less than 250 entries...
Our company is still really small and making lots of progress very quickly, we have to prioritise development where it's needed most and just use the simplest solution for other things in the meantime, but we still make sure whatever we do is suitable for what we need
Topic archived. No new replies allowed.