I debated which way to go from here - in that I can go into much greater detail on how the internet works, or I can focus more on what really is relevant to the general user. There's all sorts of important things for a network engineer to know, but going into the OSI model or the alphabet soup of various protocols (EIGRP, BGP, OSPF, as well as the TCP handshake, SYN Flooding, and more) seems more likely to cause a non-technical person to get overwhelmed rather quickly.
So I'm going to talk about databases for a bit. It's relevant, I promise, and I'll try to turn it into a personal story of sorts.
When you grow up with technology, but not a techie - in my case, at least - you just sort of absorb odds and ends as you come across them. Databases have been like that for me, a topic that started impinging on my awareness about a decade ago.
It's not that I didn't know the term, or have some general sense of what it meant, but when a colleague of mine decided our reports would be easier to work with in a database rather than the excel files we'd been using, I started learning more about when and why their important.
And the key to understanding the most common type of database is to understand relationships. That is, if you wanted to create an excel file for customer orders you would probably have to enter in the customer name and address for every single time that the customer placed an order.
If it's in a database, on the other hand, you can have a customer table and an order table, and establish a relationship between the two (i.e. a customer id number). In the customer table you only have to enter the address once, but because it's associated with the corresponding customer id in the order table you can easily create a table showing all the orders that customer has placed. Including the mailing address.
Businesses use these all. the. time. That way you can have a table showing all your employees, and a separate table showing all the wages paid, as well as a table for all customers, and a table for all the orders they placed, and a table for all the bills charged to the customer... and businesses can run queries against that database to get the information they need. Like a history of all the orders a particular customer placed, or an aggregate of all orders from a particular region, or all the customers who owe the company money.
Although I've worked more with Microsoft Access than the big enterprise databases (Oracle, MySQL, SQLServer, etc.) but most have a similar structure for querying the data - Structured Query Language (hence the 'SQL' in the databases above).
SQL statements are actually fairly obvious when you keep them simple, though they can grow to be horrendously complicated. A basic query might look like this:
It's basically saying you want to select everything from the Users table where the name is 'foo' and the password is 'bar'. (The * is a wildcard, it means select everything that matches the criteria)
So why is this important?
Well, websites these days are interactive. You don't just download a page and read what it says. You login - to check your bank account, or the news for a site you've subscribed to, to check your friends on Facebook, or post to Instagram, check your employee benefits, request time off, or any number of things online - and that login is generally used to find your specific information in a database.
When you go to a website, well... to use the postal service analogy, that site is getting thousands and thousands of letters a day, and it is passing your particular information to a warehouse (the database) that processes your request and sends back the information you wanted.
The website and database together have to a) keep track of your mail vs. all the other user's mail, so you don't have to send your username and password every time you send a letter and b) make sure that you only see your information, it doesn't send you someone else's response or let someone else see yours.
That means businesses operating over the internet generally have a way of tracking your session (that's where cookies come in to play, though it's not the only way of doing so) and some sort of system for authenticating you as the user and granting access to the information you are authorized to see.
And most of those have to deal with the exact same problem I listed when describing the buffer overflow - user input.
So I'm going to talk about databases for a bit. It's relevant, I promise, and I'll try to turn it into a personal story of sorts.
When you grow up with technology, but not a techie - in my case, at least - you just sort of absorb odds and ends as you come across them. Databases have been like that for me, a topic that started impinging on my awareness about a decade ago.
It's not that I didn't know the term, or have some general sense of what it meant, but when a colleague of mine decided our reports would be easier to work with in a database rather than the excel files we'd been using, I started learning more about when and why their important.
And the key to understanding the most common type of database is to understand relationships. That is, if you wanted to create an excel file for customer orders you would probably have to enter in the customer name and address for every single time that the customer placed an order.
If it's in a database, on the other hand, you can have a customer table and an order table, and establish a relationship between the two (i.e. a customer id number). In the customer table you only have to enter the address once, but because it's associated with the corresponding customer id in the order table you can easily create a table showing all the orders that customer has placed. Including the mailing address.
Businesses use these all. the. time. That way you can have a table showing all your employees, and a separate table showing all the wages paid, as well as a table for all customers, and a table for all the orders they placed, and a table for all the bills charged to the customer... and businesses can run queries against that database to get the information they need. Like a history of all the orders a particular customer placed, or an aggregate of all orders from a particular region, or all the customers who owe the company money.
Although I've worked more with Microsoft Access than the big enterprise databases (Oracle, MySQL, SQLServer, etc.) but most have a similar structure for querying the data - Structured Query Language (hence the 'SQL' in the databases above).
SQL statements are actually fairly obvious when you keep them simple, though they can grow to be horrendously complicated. A basic query might look like this:
SELECT * FROM Users WHERE Name = 'foo' AND Pass = 'bar' It's basically saying you want to select everything from the Users table where the name is 'foo' and the password is 'bar'. (The * is a wildcard, it means select everything that matches the criteria)
So why is this important?
Well, websites these days are interactive. You don't just download a page and read what it says. You login - to check your bank account, or the news for a site you've subscribed to, to check your friends on Facebook, or post to Instagram, check your employee benefits, request time off, or any number of things online - and that login is generally used to find your specific information in a database.
When you go to a website, well... to use the postal service analogy, that site is getting thousands and thousands of letters a day, and it is passing your particular information to a warehouse (the database) that processes your request and sends back the information you wanted.
The website and database together have to a) keep track of your mail vs. all the other user's mail, so you don't have to send your username and password every time you send a letter and b) make sure that you only see your information, it doesn't send you someone else's response or let someone else see yours.
That means businesses operating over the internet generally have a way of tracking your session (that's where cookies come in to play, though it's not the only way of doing so) and some sort of system for authenticating you as the user and granting access to the information you are authorized to see.
And most of those have to deal with the exact same problem I listed when describing the buffer overflow - user input.
No comments:
Post a Comment