Show Posts
5461
Random Chat / Re: The Official S.net "The Lame Replies Thread" Thread
« on: October 01, 2007, 06:38:16 AM »Since I can't simply connect to the server from the MySQL client I downloaded, I have to write pages to do all the SQL queries for me :/
Yeah, it's probably set up so that only 1&1 web servers can connect to the MySQL server.
Still not sure if there is a safe, secure way to hook you and Kuroneko up with PHPMyAdmin or something similar...
Also, is the Primary Key sequential or anything? I don't know much about it except that it's likely the best way to go about making my update function work.
The primary key ensures that there is at least one unique value in every row of a table in a relational database. I don't believe it's sequential by default; you may have to specifically set that column to autoincrement. I honestly don't remember.
If you want to know what the primary key is actually used for, see the end of this post.
Also, PERL would be the true techie hell. Not only is it worse than PHP, it's just plain fucking UGLY.
Perl makes up for it in a way by how ridiculously powerful it is. I actually intend to learn that.
The biggest problems with PHP are that (1) the language is a giant pile of kludges and inconsistencies and (2) you have to fight with HTML code to get all of the major web browsers to render your code properly. In my experience with PHP I've pretty much come to the conclusion that it's just a bad language.
I think I'd actually have fun doing web applications with Mono/.NET, mainly because those languages actually make logical sense and don't feel like a giant workaround.
...
And now for my primary key explanation:
The primary key isn't a very big deal in single-table "databases" but when you start linking tables together it becomes incredibly important.
For instance, let's say you have two tables, users and posts. The posts table has three columns -- id, message, and user -- and the users table has two -- id and name. In both tables, id is the primary key. Let's say, for the sake of argument, that our users table looks like this:
| id | name |
| 0 | Spectere |
| 1 | Bobbias |
| 2 | Zakamiro |
| 3 | Kuroneko |
Now, what we want to do is link the two tables so that the numbers in the user column in the posts table correspond to the users on the system. This, in effect, creates a one-to-many relationship between the users table and the posts table -- one user can create make posts.
Since the id column in the users field is set as the primary key, each row in the table must have a unique value in this field. As such, this value will be used to link the two tables together.
With that in mind, let's take a look at the posts table:
| id | message | user |
| 0 | Hey guys, what's up? | 0 |
| 1 | You smell funny. | 1 |
| 2 | wtf =( | 0 |
| 3 | Yeah dude, you're seriously rancid. | 2 |
| 4 | No joke. | 1 |
| 5 | ... | 0 |
| 6 | ...wait, what? | 3 |
With a bit of creative SQL trickery (that I don't feel like remembering at the moment) you can join the two tables together and pull all of the necessary data (message id, message, and username) with one query, essentially giving you this:
| id | message | name |
| 0 | Hey guys, what's up? | Spectere |
| 1 | You smell funny. | Bobbias |
| 2 | wtf =( | Spectere |
| 3 | Yeah dude, you're seriously rancid. | Zakamiro |
| 4 | No joke. | Bobbias |
| 5 | ... | Spectere |
| 6 | ...wait, what? | Kuroneko |
Had we used a column that could potentially contain the same data between two rows, the results could have been ambiguous. The database engine does both the grunt work of ensuring that no two rows in a table have the same primary key and makes sure that the DBA doesn't do something silly like try to join a table by a column that could potentially have repeated values. Thanks to MySQL doing a fine job in making sure that the programmer doesn't make any obvious mistakes, I'd have to say that working with SQL is the most enjoyable part of designing a web-based, database-driven, PHP application.
...whew. I think I'm going to go to bed now.
