An apology in advance, I didn't make this sound very easy so I color coded the steps I recommend. Which, admittedly, is like 4 sentences.
An SQL Database is basically a series of tables used to look up information. Imagine it like an Excel workbook. Say you want to log all of your workouts in this workbook, so you create a sheet for how many miles you run each day. Two of the columns would be
Miles &
Time. You could then create more columns for more information, maybe you want to log the temperature, date, time of day, etc etc. But now you want to add more workouts. You can't use the same sheet because you'd start mixing up your runs with your bench presses and you can't really use the same columns for those two things.
So, you create a new sheet. On this one you have the weight you benched, how many reps you did, and how many sets you accomplished. You could even add in extraneous info like if the weights were iron or dense rubber, if you used a particular technique, etc etc. Using a database is very similar.
For example, Cemetech uses a sheet for all the topics created. So
Code:
Topic ID | Title | Date
1234 | Topic 1 | DateTime Created
1235 | Topic 2 | DateTime Created
1236 | Topic 3 | DateTime Created
etc...
Where each pipe is a new column.
Then, in a new table we have all of the posts.
Code:
Post ID | Topic | User | Date of Post | Content
111111 | 1234 | 333 | DateTime | Blah blah blah
111112 | 1234 | 934 | DateTime | Blah blah blah
111113 | 1236 | 446 | DateTime | Blah blah blah
111114 | 1234 | 123 | DateTime | Blah blah blah
111115 | 1235 | 313 | DateTime | Blah blah blah
So, when you load a topic the viewtopic.php script looks up the data and displays it. It'd be really cumbersome to have the posts and topics in the same table. Our list of users is in a third table, our program archives are in yet a fourth table. And there's a bunch more tables that make up the forum too. Don't try and store everything in one table.
For example, I'm making a site that will use at least 3 tables per page. I'll have a table for the main text, a second table for links supporting the main text, and a third table showing the scores for those links. Then there will likely be additional tables to support comments and other things too. It's been on the back burner for a while but I'll hopefully be picking it up again soon.
MySQL is a big thing to learn. So, take it in chunks. Work on learning how to display info from one table. Which, sounds like all you need to do. Looking at your use case, password protected page that has a form to add code into another page. You will need two tables but you'll only use one at a time. One to sign in, the other to modify/add the code.
You could store the username and password as a text file but best practice is to use a database. It'll be easier to support multiple users AND track when the log in. For instance, you can have the following columns on the login table:
Code:
User | Password | DateTime Last Logged in | IP
That way you can verify you last logged in and if that log in was malicious (changed the code to something else) you can check to see if the IP is associated with the school or somewhere far away. The flaw here is that it would only save the last login info. So, if a user logs in again the IP and DateTime would be overwritten. Thus, you could even go one step further and create two tables for logging in: One with the username and password and a second for all login attempts (failed or successful). That way you can log a history for each user. Then you'll be able to see if an IP is regular or not. But, for the sake of simplicity and learning, let's just create the one table.
For the second table, you'd have something like this:
Code:
Content | DateTime
This is assuming you only have one page you wish to update via this method. I added the DateTime in there so, if desired, you can add a "This was last updated on: DateTime" on the page you'll be changing via this method.
Now, best practice would be something like this:
Table 1
Code: Page ID | Page Title
Table 2
Code: Page ID | Content | DateTime | User
When you log in, Table 1 is displayed. Allowing a user to select which page they want to edit. Then from there, you use the selected Page ID to look up the Page ID in Table 2. When displaying the content to visitors you'd use the Page ID to look up Table 2 and display the contents.