Visual Basic Database Tutorial - Part 5, Page 3
"So what should you do?", I hear you cry. Enter stage a secondary table.
Let me explain; imagine having one table holding all my basic information like this:
|121||Karl Moore||The Infirmary|
And then a secondary table holding information about each of my pets with the details of each animal on a new line like this:
That's great, but what links Wiggles the iguana to its owner, me, Karl Moore?
You probably noticed my customer ID number in the first table. And likewise, the second table also holds an ID number
So any pets in the second table with the ID number of 121 belong to the owner with an ID number of 121 also. Simple, eh?
Top Tip: No self-respecting geek calls those matching values, err, matching values. Instead the ID field in the main table is known as the Primary Key and the ID field in the second table is known as the Foreign Key.
And a good database design really isn't awfully difficult to program around. Let's say you allow your user to browse through the main list of owners and have a list of pet names for that owner displayed in a DataGrid at the bottom of your screen.
You'd simply tell your program, in geeky programming terms: "Every time the user moves a record in the main customer table, display all the details from the pets table where the ID number in the pets table is the same as the current customer's ID number".
OK, so it might sound a teensy-weeeensy bit complicated. But it ain't. Really.
At least, not for mega supercool geeks like you and I...