HartleySan

I trust that the double post was a glitch in the forum and not you double posting on purpose, right? Didn't mean to sound rude there. Anyway, all you need to do to get the number is access it via $_GET['PHPSESSID']. Also, no offense, but if you're not even able to do that, I don't know why you're worried about trying to simulate session fixation attacks.

Sorry for neglecting the anchor text, the link and the alt tags. All the same though, I'd just add them to the one table, even if at least one value is NULL 50% of the time. Well, like you said, we've kinda beaten a dead horse with this one, so we'll just let it go. In the end, you got a lot of join practice, and it really does come down to preference at a certain point, so I can't say that one is better than the other.

I don't have the book in front of me, but going off what I remember of Larry's example in his PHP 6 & MySQL 5 book, I'd doing something like the following: Have some sort of admin screen that lists all (or just some of) the products. On that screen, in an HTML table, have a Delete link for each item. The Delete links would have to be coded using something like the following, which would most likely be performed from a PHP while loop after grabbing all the necessary item info from the database: echo '<td><a href="deleteitem.php?id=' . $row['id'] . '">Delete</a></td>'; And then you'd have to write the deleteitem PHP script, which would receive the ID value via the GET method, and use that to delete/flag the appropriate item. The code might be something like the following: $id = $_GET['id']; $q = "DELETE FROM table-name WHERE id=$id"; And then you'd execute and verify the query, etc. Or if you wanted to adjust a flag, your query might look like the following: $q = "UPDATE table-name SET active_flag='inactive' WHERE id=$id"; Anyway, I hope that helps. Also, please keep in mind that this example is greatly simplified. You'd need to write the rest of the scripts, and also, you need to consider security issues, so that random people can't just delete whatever.

First off, there are two schools of thought on deleting data from a database: 1) It's okay to do. 2) Don't delete the data, but instead create an active/inactive flag, and change that flag. I tend to prefer the second option. In general, it's best to avoid deleting data from a database. By using a flag, you can simply test for whether the flag is active or not, and if it isn't, don't display the data. With that said, the easiest way (as is the case in Larry's PHP 6 & MySQL 5 book) is to send the ID of the record to be deleted to a script used for deleting, and from there, ask the user whether they're sure they want to delete the record. If they say yes, then with the ID you have, you can either delete the corresponding record or you can toggle the activity flag, depending on whether you go with 1 or 2 above. Does that answer your question? If you're going for something else, then you'll need to provide some more info about your specific example.

bnorg, related to Larry's last comment, his PHP 6 & MySQL 5 book is really good, and teaches the fundamentals of both. I highly recommend it.

I'm kinda hoping that either Larry or Matt will chime in eventually, as their database design knowledge far exceeds mine (it's one of my weaker points). However, I still feel that one table is fine. I think at this point though, it comes down to a matter of preference; how far do you want to go to normalize your database? Keep in mind that normalizing your database does help decrease the odds of data integrity issues, but it also comes at the cost of performance. Having to occasionally use NULL values when appropriate is perfectly fine, I think. I feel like where my thinking differs from your is that you are thinking that for the home page, you'll only need certain pieces of information, whereas on the individual people pages, you'll need other pieces of information, and you are seeing this as an impetus to create multiple tables, one for each page. This, to me, does not equate to the need for more than one table. I think it simply means that you only need to pull the key pieces of info for particular records, depending on the page. As for SEO friendliness and accuracy, that simply comes down to two things, I think: 1) Using good, semantic HTML, which is unrelated to the database structure. 2) Picking good terms/values for the meta tags, which again, is unrelated to the database structure. So in the end, I'm sticking with my idea that one table is okay, but I'm also willing to relent on the fact that having more tables isn't wrong, but more a preference thing. I tend to err on the side of performance, even if that means using a few extra NULL values here and there. Similar to another post Larry made recently, if you feel that you will continually be using the same content for a field, then by all means, pull that field out into a second table. Again though, I think that's a preference thing. To me, if the values in a field are not dependent on each other, even if there is some repetition, that's fine. For example, a listing of persons will more than likely have multiple John Smiths, but I would not personally see that as grounds to create a foreign key for the name, and store the name John Smith in a separate table. Again, some people might disagree with me, but I don't think either is wrong, and common sense tells me not to take things that far. To be more specific with your provided example, I'd have a persons table with the following structure: id name metadata // Perhaps comma separated, or whatever is necessary. page_title // If this is just some variation of the person's name, this might not be necessary. short_desc full_desc image_path last_modified And for the home page, I'd pull the name, image path, short description and ID from the database. The ID would be used for the links, of course. And from the individual pages, I'd pull the name, page title, metadata and long description from the database. Of course, this would be for the record with the ID retrieved via the GET method. Anyway, I can't think of any simpler, more straightforward way to do it. If you want to complicate things with more tables, go ahead, but I don't think it's necessary (but it's not wrong either). Sorry if my post got repetitive there. Just wanted to make sure my point was clear.

I think you're right, Jorge, in that conceptually, it does sound easier to use than a relational database. That is an advantage, as it saves time for even the most seasoned developers. Basically, it just uses object notation to store everything, so your data is always ready to go. I still think it'll introduce a whole slew (of perhaps not yet known) headaches in regards to data integrity though.

Here's my best attempt at answering your questions: (2A) I don't have the book in front of me, and honestly, I'm a bit confused about this, so I can't comment on this at the moment. (2B) You can very easily created constants for messages, and use those constants for messages. The easiest way would be to place the constants in the config file that already contains other constants and is loaded into most scripts. That way, you don't have to include any other files. (3A) Database calls are expensive any way you slice it. And ASP does not magically work faster than other scripting languages. If anything, I'm willing to bet that ASP (even the new version) is slower than PHP. What I can say though is that using stored procedures (or prepared statements) is faster than running individual queries every time. They're faster because the queries are already prepared before you make a call to one, thus reducing the time need for each one. (3B) I think it's best to take the examples in Larry's books as just that, examples. I think he provides short, simple messages just to get the point across. You're welcome to expand on them as much as you want.

Thank you for taking the time to explain all that. I know how frustrating it can be when you explain something, and the person on the other end doesn't seem to get it. I do think I understand it now though. With that said, I still think you only need one table for what you're doing. Errr, let me rephrase that. I think you only need one table for the way you're doing what you're doing. Using more than one table makes it seemed really forced. You even said yourself that you want multiple tables, so that you can practice joins. If it were me, I'd bring things back closer to Larry's coffee site. Basically, you could have different categories for camera equipment, and within those categories, individual cameras. And within the cameras table, I'd add little blurbs about the cameras, etc. Anyway, do what you gotta do, but if you're organizing your site on blocks of content, multiple tables does not seem necessary.

As an added note, you could run the fax number through a filter that strips out all spaces, parentheses and hyphens. Just run a simple string replace.

Yeah, I'm in agreement with you Jonathon. I think for people like us, we can understand when it's appropriate to employ such technologies (which is rare), and when to stick with standard relational databases. However, for the IT managers of the world that don't understand the technology and are easily swayed by buzzwords, I'm sure they'll quickly jump on board with this "new" technology, which guarantees "faster" performance. Honestly, though, the headaches cause by going through all the checks to guarantee the integrity of the data seem to far overweight the benefits in all but the most extreme of cases (e.g., Facebook). Nevertheless, I found the article to be interesting. More than anything, I don't see this as a new technology or idea, but rather something that has become more relevant as disk space is no longer at a premium, and the time needed for a developer to deal with the interface between the application and the database is more valuable than possible integrity issues. But again, I don't really buy the latter argument so much, as interacting between a database and an application is so common these days, I don't think most developers have issues with that, and the new issues that will arise with developers having to deal with data integrity issues they have never experienced before will be mind-boggling.

Thanks for commenting, Larry. And that's exactly what I was thinking. I was thinking, well, it makes sense for the big boys, like Google and Apple, to use this technology, but for the average developer, does it matter? No, not really. And really, I think you'd need to be the likes of Google and Apple (with some really awesome developers on staff) to ensure that the integrity of data is always, always preserved properly. Anyway, thanks as always for your insight.

Sounds good. Good luck with that.

Agreed. With the HTML5 doctype though, it should be okay.

Thanks for the heads-up on PayPal and their documentation. It's always good to know. Also, I literally just re-read the MySQL book yesterday and today (I had a lot of free time at work and wanted to review it). As far as I can tell, the content is still rock-solid and relevant.

Cool. Glad that worked. Also, I'll check out the admin area of WordPress sometime soon. I'm curious now.

To be honest, I think you need to take a step back and rethink your form to begin with. I don't see any reason why you'd want to separate one form into two distinct-looking divs. I think it would only serve to confuse the user. With that said, if you really wanted to do want you want to do, you'd create one form, and then put separate divs within that form. For example: <form> <div> // Input items here. </div> <div> // Check boxes here. </div> </form> That is syntactically correct and would work in HTML, but semantically speaking, it's a mess, and I would not encourage it. Anyway, that's hopefully the answer you're looking for, but again, if you feel the need to do this, I'd rethink your design first and foremost.

As per a discussion I had with Matt (a fellow poster on this forum) last night, it looks like a lot of companies are looking past the relational database these days for high-end, highly scalable systems. The following article talked about the possible successor to the relational database, and I thought it worth sharing here: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php Would love to hear all your comments. I will hold back on sharing my own comments until some other people post their own comments.

Put it all together into one form?

I thought about your schema for quite a bit, but am still confused. To me, and again, this is just off the top of my head, it seems like with things like articles, there is no chance of data redundancy. I mean, each article has a title, content, a general description, a link to the article (I think) and perhaps some metadata about the article. I don't see why all this information can't be in the same table, since it would more or less be unique to each article. I suppose the one exception would be the metadata, which might be shared, in which case, by all means, make a separate table for that. Still though, I'm having trouble imagining the need for all those tables. I do trust you know what you're doing though, Jonathon, so more than anything, I just want to understand the logic behind your decision.

Personally, I don't think it's an issue at all if most customers choose unoriginal and repetitive names for their coupons. Keep in mind that each coupon is a separate entity and has no dependency whatsoever on other coupons. That's the key. Each coupon is independent of other coupons, even if a lot of coupons happen to share the same name. Think of it this way: If I customer were (hypothetically speaking) able to change the name of their coupon, the fact that the name of their coupon was changed from "SALE" to whatever would have no effect whatsoever on other customers' coupons named "SALE", right? As such, you're fine with the "redundancy", which is not really redundancy, but a by-product of unoriginal naming. Anyway, that's my two cents.

I don't think that much has been added to MySQL since Larry published the MySQL book. Seems more logical to focus his efforts on possibly expanding the e-commerce book or releasing the much-anticipated JS book.

Yeah, definitely, you want to join on content_id, not page_id. I mean, if the links link to the content, I can't imagine links and corresponding content being on the same page. Well, I could imagine some other content and links on a page, but I digress. Also, since the field names are the same for the keys, USING (content_id) works fine. You could also do ON content.content_id=links.content_id. Lastly, I'm assuming that your links table is named links, not link, right? I think that might have been a typo on your part. More in general though, if each piece of content has a unique link and anchor, then separating the info into two tables seems unnecessary to begin with. I don't mean to discourage you. Just something I thought of. Of course, I don't know the full situation either, so perhaps my comment is completely irrelevant. As you may recall, I started that post regarding joins a week or so ago. Through that post, everyone's suggestions and really thinking about joins a lot, I think I finally understand them. Now, when I look at the examples in Larry's book, they're so simple. It's amazing the change. Anyway, you seem to be at the same point as me, so it's good to know that you're taking that knowledge and applying it. Good luck.

Again, it depends on what the print items apply to. Are the print items dependent on the categories or the individual items? Whichever one it is, that's the one you have to place a foreign key to in the print items table. Make sense?

Well, no reason to bash yourself. I had to outsource the idea to a friend that's quite good at HTML/CSS. So as you can see, I couldn't think of anything good either.