Denial of service attack.
It says the file is local (with the client) not on the server.
Probably you should edit your CSV file to rename the header or just remove the headers.
The parsing is just as easy, but I think human error happens more with CSV. You might have a CSV file with a NAME column, and someone enters their name as "Anderson, Scott". Now, one of your rows has an extra column, and the "Scott" has moved over to the BIRTHDATE column, and, well, nothing good is going to happen.
Yes. We can use the alter table statement. We'll do that later this semester. We will not need to do it yet.
ALTER TABLE can add indexes
Not as far as I know.
Well, I can't show you what they look like. But think about an index in the back of a book, listing the page numbers that something is on. The page number is the primary key. The index is additional.
We might add an index for PERSON for NAME and MOVIE for TITLE, since we will often look things up by those values.
If you had find occurrences of "Rosalind Franklin" in a biology textbook, would you rather go page by page or look her up in the index?
Presumably, it keeps a list of the locations of those rows, like our Rosalind Franklin example, whether they are the same ID or different.
An index means we can look things up faster.
Sure. It's a data structure that has a bit more bookkeeping info in it, so it can enforce referential integrity, while MyISAM can't.
There is probably some price to be paid in performance or storage for the extra power. Almost every choice involves tradeoffs.
Sure. we'll work through some examples. If a DEPARTMENT in some company is abolished during a reorganization, we don't necessarily lay off the employees. We might set their department field to be NULL.
I don't see any reason to delete the owner. They may get another pet.
Good question. The TRACK table has a foreign key into the ALBUM department. So "Shake it Off" refers to "1989". But that album no longer exists, because none of the albums exist, because the table was dropped. So, that's not allowed.
No. We want the foreign key to be valid. A pet *must* have an *owner*, but an owner need not have a pet (yet). An track *must* have an album, but an album need not have a track (yet).
If it were two-way, it would be difficult to insert any data!
We need the foreign key clauses. I think the INDEX is no longer required if it's a primary key.
We wouldn't. I think that part of the syntax is no longer required.