If for some reason a database is out of the question, then you need to answer the following question about your problem:
What is the mix of the following operations?
Once you have a good guess at the ratio of these operations, try selecting the appropriate data structure for use in your file. I'd recommend starting with this book as a good catalog of options:
You'll want to select a data structure with the best average and worst case runtimes for your most common operations.
"Introduction to Algorithms" by Cormen, Leiserson & Rivest. See http://www.amazon.com/Introduction-Algorithms-Second-Thomas-Cormen/dp/0262032937
If you can get your hands on a copy of Cormen et al. "Introduction to Algorithms"
It's a very very good book to read up on data structures and algorithms.
Best way forward would be to work on your skills. Although its a long shot but follow some of the advice for novice programmer. You can look for Steve Yegge's post on interviews and Joel on Software. These will guide you through this landscape.
If you want to learn programming from ground up. Here is my list:
3. A Data structure book
4. Some basic book on the programming language of your choice.
The list may go on but you need to go through them in full steam.
Best of luck.
"The Art of Computer Programming" (http://www.amazon.com/s/ref=nb_sb_ss_i_6_31?url=search-alias...)
....to begin with.
Then there are theoretical computer science books.
I like the Computability, Complexity, and Languages, Second Edition: Fundamentals of Theoretical Computer Science (Computer Science and Scientific Computing)
They will, with time. Colleges are slowly moving to Python instead of Java. With time, so will employers and the AP's. Then, slowly, schools will.
This is one thing you learn painfully as you get older - there are a million changes that should happen now, in a perfect world. In the world we live in, change happens slowly - money needs to be allocated to hire new teachers, which takes time, new teachers need to be interviewed and hired, which takes time. Old teachers need to be trained, which takes time, etc. A new teacher has to prove herself as being competent before a high school introduces a new curriculum only she knows, because they don't want to invest developing tests/homework problems/syllabi that will be useless if that teacher quits/gets pregnant/gets hit by a bus.
If you're serious about programming and programming languages, though, forget about learning a thing in high school, work for the grades (if that's your style), and learn things on your own. Don't do it to show off to your friends - they're an inexplicably minute fraction of the world at large - impressing them is like a minnow trying to impress his puddle. There will be a lot of people much smarter than you if you get into a good college.
Save up your lunch money for these books, and get through as much of them as you can before grad school (or work):
That gives you 5 or 6 years, not nearly enough to really get these things, so make time. And... GO!
PS. consider it a big step in the right direction when you "get" Lisp.
The single most helpful tool I've had for algorithms is Introduction to Algorithms.
It's the single best resource I know of for algorithms. It covers so many topics in good depth and has examples throughout. I still refer to it quite frequently.
Without that book my algorithms analysis class would have been a pain.
Vertices are the dots, edges are the lines. Hence cities and roads.
I'm not sure what confuses you, but in general graphs are indeed used to model connections between objects.
If you have a bunch of objects (vertices) that may be "connected" to one another, a Graph would be the high level data structure to maintain it. I'm saying "high level" because in practice you will probably need supporting data structures to maintain a graph in memory/database/file: matrices, lists of links, many-to-many tables etc.
If the "direction" is not important, like in the case of the plot above (i.e. all roads are bidirectional), you have an "undirected graph". If the connection direction does have an importance (for example if there are unidirectional roads between cities), you'll have a "directed graph", where every edge is actually an "arrow", pointing at a certain direction.
If you're very new to this, I recommend reading the relevant Wikipedia entry. For some "real" studying, I recommend Cormen et al's Introduction to Algorithms, the book I studied from, which is in my opinion one of the best computer science books ever written.
That's not too far from the truth. There are a couple of systematic methods, but they are hard work, and even then they tend to get "shortcut" at some point.
Big-O gives an upper bound. If someone asks you for any algorithm and you don't know, you can say O(n^n) and probably be correct (though there are even slower algorithms out there). It's not a tight bound, of course.
The "shortcut" is basically the point of inspiration when you spot a pattern that proves some particular upper bound.
99% of the time, most people just use their intuition to find a good way to look at the algorithm, and then do just enough to prove that bound. For example, instead of looking at the actual flow of execution, it is common to say "each item is processed at most x times, each time taking constant time" (for an O(n) algorithm). You may have missed the fact that e.g. at most log n items are ever processed, but if you really grok what the algorithm is doing, that's reasonably unlikely.
Of course this probably won't get you through an algorithms course.
For the systematic methods - well, there's the "MIT 6.046J / 18.410J Introduction to Algorithms" course videos which can be viewed on YouTube. The lecturer is one of the authors of a very well respected algorithms textbook.