Competition - post a photo you've taken of nature >>

Self-teaching SQL and other programming languages

Hello TSR

I have no prior experience to programming with computer languages however I have found for several roles SQL is a skill in demand by employers. I would like to how difficult this would be to achieve and if there are alternative languages which are easier learn and to some degree less boring.

Cheers

Posted from TSR Mobile

Scroll to see replies

Reply 1

ApplyYourself

Original post by Singh89

Hi mr Singh :smile:

I've no programming experience at all.. But apparently sql is an easy language, however, you need to have a logical mind/approach to things.

I found this site which may be helpful for a beginner:

http://sqlzoo.net/wiki/Main_Page

Reply 2

username234673

Original post by Singh89

SQL is a piece of cake to start with and can get very complex once you master it. You can download a 180 day trial of SQL Server from MS at: https://technet.microsoft.com/en-gb/evalcenter/dn205290.aspx

Give that an install and use their Adventure Works database to get yourself started.

There are plenty of resources available on the net for learning SQL code. I'd recommend starting with some basic SELECT, DELETE, UPDATE and INSERT statements. :yep:

This is your bread and butter SQL stuff.

If you have any questions, feel free to PM me or quote me in here. I've been working with SQL server for a good number of years now, so I should be able to help you out, or at least point you in the right direction.

Finally, if you want me to check any code, use the [noparse] and [/noparse] tags, to make your code look like this:


SELECT username, post_count
FROM dbo.user_header
WHERE user_name = 'Singh89'

Returns:
Singh89, 62

Reply 3

Planto

Original post by mikeyd85

Or get the Express edition for free forever!

Reply 4

Flame Alchemist

SQL is relatively simple language, one that's designed especially for data handling and databases. If you've got a computing job in data management, or are looking for one, it's going to be your bread and butter.

If you're just looking at computing jobs in general, though, it's an unusual language to learn first because of its special, specific purpose. For general programming, it's best starting off on something fundamental like C++ and/or Java.

Reply 5

Mad Vlad

Original post by Singh89

Just remember the golden rule...
DROP *
FROM *
Will troubleshoot any problem you have.

Reply 6

cbartlett

I wouldn't recommend SQL as a first language.

It is relatively easy to use, and relatively useful. However, in terms of programming, you'd be better learning a third-gen language such as Python or PHP. SQL is meant to be used in conjunction with another language really. Alone, it's not really much use

Reply 7

A5ko

If you have the inclination, go straight for the jugular and learn Java.

Reply 8

Planto

Original post by A5ko

If you have the inclination, go straight for the jugular and learn Java.

Reply 9

Async

Original post by mikeyd85


SELECT username, post_count
FROM dbo.user_header
WHERE user_name = 'Singh89'

Returns:
Singh89, 62

Express edition is free for life.

Also, your SQL statement is not representative of what is actually used. You don't store the post count on the user table. You find the post count by selecting the total number of posts a user has made. If you were to store post count on the same table as the user table then you'd have to update the user table each time a user makes a new post. That's like storing somebodys age. You don't store somebody age because your age changes very frequently. You just store their date of birth, and upon request you can easily calculate their age. Same logic.

Also, selecting where user_name = 'Singh89' might be a bit ambigious if there's multiple users with the same name, unless user_name is a primary key. Typically, a UserID is used to search for a users data since that's always the Unique Primary key.

Also, you have two fields to store the same thing?
[SELECT username]
[WHERE user_name]

you have username and user_name. Unless that was a typo.

(edited 9 years ago)

Reply 10

Computer Geek

I wouldn't start with a query language, I would start with something like VB.NET/Java/Python.

Reply 11

Planto

Original post by Async

You don't store the post count on the user table. You find the post count by selecting the total number of posts a user has made.

Could be a view :wink:

Reply 12

username234673

Original post by Async

Really, it was just an example of what the [noparse][/noparse] tags would do with information that could be easily related to on the screen at the time.

I do think post count would be store though. If each time a person loads a webpage, a COUNT statement is run to work out each user's post count, then TSR has much, much more server power than I thought.

Edit: I'd love to see the schema for TSR. :yep:

Reply 13

Async

Original post by mikeyd85

Every time you re-load your browser you fire an SQL command. Modern SQL servers were designed to execute queries fast so I don't think that would be much of a problem, as long as you have good enough servers.

But I do see your point though, if a user has made so many posts surely that would take a lot of server power to process.

But then again, I remember selecting the count of data which returned 8K. And it returned the data instantly. Select the count of something is different than to displaying the table data.

Select Count(*) From tblPost

is wayyy different from

Select * From tblPost

Count is quicker, I'm sure there is a way they do it in order for it to be fast. I think it's because they don't have to render any data to display.. All they show is an Integer.... Soo yeah.. Maybe we can get a database expert to shed some light on this.

(edited 9 years ago)

Reply 14

username234673

Original post by Async

I reckon asking in this thread would probably get the answer! :lol:

Much of this will be down to the schema of the db.

Reply 15

Async

Original post by mikeyd85

I reckon asking in this thread would probably get the answer! :lol:

Much of this will be down to the schema of the db.

Done. Now let's wait for his reply :biggrin:

Reply 16

Planto

In SQL Server, [pre]COUNT[/pre] is an O(n) operation in terms of the counted items. So it is more expensive to count on the fly than to store a count and this will scale linearly with the number of posts that have to be counted.

Not only that, but every row has to be loaded in full in order to count it (unless you have a non-clustered index against the table, in which case only the index keys have to be loaded, which will dramatically reduce I/O time).

When there are large numbers of rows to count, there is a case for storing a count separately. Or, better still, use a more appropriate storage mechanism for your posts (such as a document database) and count them in O(1) time by simply indexing the post count against each user.

I presume other SQL platforms are similar.

(edited 9 years ago)

Reply 17

Async

Original post by Planto

In SQL Server, [pre]COUNT[/pre] is an O(n) operation in terms of the counted items. So it is more expensive to count on the fly than to store a count and this will scale linearly with the number of posts that have to be counted.

Not only that, but every row has to be loaded in full in order to count it (unless you have a clustered index against the table, in which case only the index keys have to be loaded, which will dramatically reduce I/O time).

When there are large numbers of rows to count, there is a case for storing a count separately. Or, better still, use a more appropriate storage mechanism for your posts (such as a document database) and count them in O(1) time by simply indexing the post count against each user.

I presume other SQL platforms are similar.

Makes sense, I was thinking something similar to something being Indexed but I couldn't put my finger on it.

Reply 18

Planto

Original post by Async

Makes sense, I was thinking something similar to something being Indexed but I couldn't put my finger on it.

I think there are tricks you can use involving scanning system tables and so forth to retrieve quicker (but potentially less accurate) counts but if you're gonna go down that route you have to start wondering if it isn't worth just storing a count separately.

Reply 19

jenhasdreams

Original post by Async

Done. Now let's wait for his reply :biggrin:

Her reply

Yes we store the number of posts against each user in the user table, which is updated whenever a post is made. It would be very slow to calculate the number of posts for a member every time that member profiles is loaded, as there are over 5 million posts.