"familiarity with SQL"

[hiromizu]

As long as you've heard of it, you're familiar with it - hope that they don't ax you too many questions or your good enough to spin the discussion around into something else.

 

[ultimatebob]

Yeah... if you can do basic SELECT and UPDATE statements, you should be OK.

 

[slsmnaz]

Originally posted by: mjrpes3
Familiar means they don't expect you to be an expert. But you should know the basic syntax. You should know the difference between a left join and inner join. You should know how to pull aggregates using GROUP BY. You should know how subqueries work and how to effectively use them in both the SELECT and WHERE parts of a statement. unions, the importance of indexes, primary keys. sql is easy to learn with an intro book and a few hours time.

yep, that is exactly what I would expect from someone who says they are familiar with SQL. If you have data to work with then it's not very difficult to learn. I got to learn on the job but my "SQL- A Beginner's Guide" book sat on my desk for the first few weeks as I basically worked my way up from zero knowledge.

 

[TheKub]

When I see ?Familiar with X? in job descriptions I take that as I know what this product is, what it is used for, what are the capabilities of the product, etc. Basically, entry level knowledge of the product.

Given its not a technical position, I would say if you can read SQL for dummies and not be completely lost\confused you would fit the bill. Even if you couldn?t write queries from your head (need a reference item) Id think you would be ok.

Its likely that you wont be writing a lot of actual code you may be using something like crystal reports that you need to have a grasp of SQL but don?t need a DBAs understanding to make it sing and dance.

Now if it said ?Experienced with X? that?s a bit different?

 

[Unheard]

Just remember, on your way out when you get fired....

DROP DATABASE YOURDATABASEHERE

and for good measures go ahead and try rm -rf /

You will defiantly get a good reference from them.

 

[torpid]

Originally posted by: GodlessAstronomer

Originally posted by: Citrix
to me that is saying the person should be a fricken DBA

Not at all, everything I listed is the absolute minimum that any developer should know. If you're a developer who doesn't understand relational algebra and simple SQL stuff then I sure hope you're not working anywhere near any sort of data.

Business Analyst =/= developer. Also, I really hope you meant insert and not create. If you actually meant that someone who only needs to be "familiar with SQL" should be expected to know DDL instead of DML, I'd strongly disagree. In a properly structured business, random business analysts should not be executing DDL against the DB generally. Random developers, maybe - only in limited scenarios, and certainly not against a production database.

 

[DT4K]

Originally posted by: Citrix

Originally posted by: GodlessAstronomer

Originally posted by: Fayd
AFAIK, SQL is a database query language..right?

I don't really know how much experience they would require, but the fact that you'd ask that suggests that you certainly are not familiar enough with it.

It's difficult to say how much work you'd need to put in. I imagine some people would consider "familiarity" to mean you can write simple select statements involving maybe composite tables and simple joins, as well as update, delete and create statements. Others would consider "familiarity" to mean you know your shit about relational data, and you know enough SQL to be able to transfer your knowledge of relational algebra into a query.

I'm really guessing here.

to me that is saying the person should be a fricken DBA

Being a DBA has nothing to do with querying the database. Actually, I take that back. Update, delete, and create should generally be left to the DBA. Or at least to a developer who knows wtf they are doing. Of course, a DBA does a lot more than that.

"Familiarity with SQL" could have lots of meanings, depending on the job description.
For a business analyst, you'd most likely be working with users/clients and developers. In this case, you would probably be expected to understand the basic concepts of databases and probably have a reasonable understanding of how to query a database. Basically, you'd need to be able to communicate with developers and DBA's and know wtf they are talking about, at least at a high level.

For jobs that require you to look at data, being able to write SQL queries is helpful because in many cases, the data is there, but isn't necessarily available via reports, etc., in a form that is helpful to you. Having analysts who can pull whatever data they need to look at is a good way to prevent developers from constantly wasting their time writing up random queries for users.

When I worked for Kodak, we actually taught a SQL class to our engineering group and gave them read-only access to the database. Before this, it was a daily occurrence that someone would come to us and say, "hey, we need to look at all the data for this particular quality test on this particular product".

 

[ivan2]

prob means if they can query an access db...

 

[satyajitmenon]

Originally posted by: Unheard
Just remember, on your way out when you get fired....

DROP DATABASE YOURDATABASEHERE

and for good measures go ahead and try rm -rf /

You will defiantly get a good reference from them.

:laugh:

Originally posted by: mjrpes3
Familiar means they don't expect you to be an expert. But you should know the basic syntax. You should know the difference between a left join and inner join. You should know how to pull aggregates using GROUP BY. You should know how subqueries work and how to effectively use them in both the SELECT and WHERE parts of a statement. unions, the importance of indexes, primary keys. sql is easy to learn with an intro book and a few hours time.

This.

 

[JEDI]

Originally posted by: Fayd
when companies list things like this on their job requirements, what is it they're looking for?

this isnt for a technical position, it'd be for something like a business analyst, entry level management, (one i'm looking at now is titled "inventory analyst.")

AFAIK, SQL is a database query language..right? so are they actually looking for someone who can program database queries in SQL? or are they just looking for someone who has worked with applications that use sql?

i should mention i'm asking this because i'm curious what companies expect. i'm thinking about trying to learn certain applications and useful languages on my own to increase my marketability. (having a non-technical degree kind of sucks if it's your first degree...)

lol.. I thought sql = shorthand for squirrel
then took a 1 week class.
a month later, i was working as a dba

but yes, i would guess sql quieres given your title

 

[BlahBlahYouToo]

Originally posted by: Citrix

Originally posted by: GodlessAstronomer

Originally posted by: Citrix
to me that is saying the person should be a fricken DBA

Not at all, everything I listed is the absolute minimum that any developer should know. If you're a developer who doesn't understand relational algebra and simple SQL stuff then I sure hope you're not working anywhere near any sort of data.

eh maybe i guess im just used to people coming to us (sys admin) to data mine out of our db's and turn it into a published crystal report. I absolutely hate doing it and pawn it off as often as i can. we hired a report writer a few months ago to do this shit. just let me maintain my citrix farm and im a happy clam.

didn't citrix become xen?

 

[Jadow]

Originally posted by: Capt Caveman
They are looking for someone that can write queries against the database(s) for data extraction, reporting, etc...

yup, stuff like this

select customer, count (transactions) as Units
from transactions t (nolocK)
inner join customers c (nolock) on t.customer = c.customer
where date >= '2009-01-01'
group by customer
order by count (transactions) desc

 

[Jadow]

also, SQL you can learn on the job no problem.

 

[randay]

youre not qualified.

 

[Red Squirrel]

Probably looking for stuff like very large complex queries (several 100 lines long) that generate complex reports. My coworker used to be business analyst and he's shown me some of the queries he's used. Insane. He can take data in pretty much any format and turn it into SQL tables by using just queries. (using text modifyers like left, right, mid etc). basic select insert won't cut it.

Wont hurt to try though.

 

[AkumaX]

ATOT is smart'); drop table Users; --

 

[Jadow]

Originally posted by: RedSquirrel
Probably looking for stuff like very large complex queries (several 100 lines long) that generate complex reports. My coworker used to be business analyst and he's shown me some of the queries he's used. Insane. He can take data in pretty much any format and turn it into SQL tables by using just queries. (using text modifyers like left, right, mid etc). basic select insert won't cut it.

Wont hurt to try though.

SQL isn't hard, it's progressive, just break it up into little parts. The end query can look really complex, but it was a progression of simple steps.

 

[Evadman]

select username from users where clue = 0 and username in (select username from posts where threadid = 2307923)

username
------------------
Fayd

 

[Evadman]

Originally posted by: Jadow
My coworker used to be business analyst and he's shown me some of the queries he's used. Insane.

I actually hit the limit of characters in an informix SQL query, which is 65k characters. In SQL, I haven't hit the limit yet, which is 262 mb. However I do have a query that is just over 121k characters. It is surprisingly fast, and runs in about 10 minutes.

 

[Skeeedunt]

Originally posted by: ivan2
prob means if they can query an access db...

+

Originally posted by: Jadow
also, SQL you can learn on the job no problem.

=

You win a new job. Either way, basic SQL is definitely a good skill to have. An entry level SQL book should be more than enough to keep you busy for a while.

 

[KentState]

Sounds like a company that doesn't have a BI group to handle the reporting needs. I've been working with databases for 12+ years now and currently a Manager of Database Systems and it always chills me when users want the ability to directly query transactional systems. I've seen Access lock tables even after the user closes out the program, but the process never finishes or someone bring SQL Server to its knees with a NOT IN statement.

 

[Apathetic]

Since they're only asking for "familiarity with SQL" I suggest you know how to use SELECT, INSERT, UPDATE, and DELETE. You should also know about primary keys, indexes, and joins.

Basically, they're not expecting you to be a programmer but they want you to know how to get data out of a given database.

You should be able to get all of this from a SQL for Dummies type of book.

Dave