Prodigal Son

Yea, I will probably set things up like that except add a config.php file as well. Thanks for the help.

Yea, makes sense. I should just put it at the top of the page, I guess I overcomplicated things. Since both ways seem to be able to do the same thing (I originally thought the first way was better) I guess I'll use the second way.

Hmm, the way I learned to code (maybe it was a bad way lol) was that it's better to keep functions separate from the actual page. So let's say I have 5 functions and some simple isset logic for review.php, do you suggest putting those directly into review.php?

Hmm, using the other way I could easily create a switch statement and have cases for each view and keep stuff like function calls separate from the page. Using this method, how would create a controller type page? Would something like this work: switch (basename($_SERVER['PHP_SELF'], '.php')) { case 'review': run_function($_GET['id']); break; }

I'm coding a small database driven site and I have my index.php include the view page and call the database to make queries based on what is in the $_GET variables. So to grab a review with id 10, my url would look like: index.php?view=review&rid=10 I see a lot of sites that would have the url look like this instead: review.php?id=10 Is that a different coding method altogether? To keep it simple with the first method in my index.php I could have: -php stuff -header --include review.php file -footer Since the included files will only carry its own individual content if I need to edit the layout I could just change the index page. However the second method I would need to include a header and footer into the content on all pages? If I make some drastic changes and let's say I wouldn't even have a footer anymore or maybe I would need another sub section for the layout, wouldn't I have to go through and edit all the pages? The first method also seems like it would be easier to separate logic and layout across specific pages by grabbing the view get request if needed. Maybe I'm missing some advantages of the second method?

Ah oops, of course, forgot to do that. It's working now. Would adding that bit slow down the query much? I noticed that even scripts such as vBulletin wouldn't do that, so I wonder if it's necessary.

I actually don't want to use leading zeros. I just only want to match exact digits incase search engines treat it as duplicate content. So a url such as index.php?page=something&sid=020 would also have the same content as index.php?page=something&sid=20. Not sure if search engines will count that as duplicate content. So any leading zeros on the id should go to a 404 page instead of having the same content. Did you mean something like this: SELECT * FROM table WHERE CAST(sid AS CHAR) = 0020 I tried that but it still returned the row with id 20.

Take for example: SELECT * FROM table WHERE sid = 0020 If it finds sid with 20 it will fetch that data. Is there a way to make mysql match only exact digits? So in order to grab the data with sid of 20, you'd need only "20" and not 020, 0020, 00020, etc. Thanks.

Yea, I'm not quite sure why InnoDB didn't help me out either. I'll try moving the hits column out of the table and see if there is any improvement in performance. Just wanted to make sure it would actually make a difference before doing it and it looks like there are. Thinking about it, there shouldn't be any harm in doing so since even if it doesn't help, it shouldn't hurt.

Yea my first thought was InnoDB would improve my problem, but it actually made it several times worse. And yep, it is multiple id's that have their hits updated. I'm still just wondering if separating the hits to another table will make things better or not. I'm thinking it won't help. Is it the hits table or the info table that would be locked? If its the info table then I couldn't grab data from it, and if the hits table, then I wouldn't be able to join to it either right if I want to display the hits? Hehe I think I just made things complicated, I guess I kind of answered my own question now.

Hmm, I don't think I need it to be too complicated. Right now the table would look like: Info id |Col 1 |Col 2 |col 3 |col 4 |hits --------------------------------------------- 1 |blabla |blabla |bla |etc |100 So if I run "UPDATE info SET hits = hits + 1 WHERE id = 1" each time a page is loaded and in addition use select statements to grab info it'll lock the table. I'm basically wondering if I separate the hits into another table would it improve the situation or would it not really matter? So then I would have: Info id |Col 1 |Col 2 |col 3 |col 4 -------------------------------------- 1 |blabla |blabla |bla |etc Hits id |hits ------------- 1 |100 So now I would only run the update on the hits table instead of the info table. But if I want to grab the hits I'll need to join the tables, is that still the same as selecting and updating the same table or would this be better? Hopefully you get what I mean now.

I tried InnoDB but it ended up being even worse since the queries generate a lot of count(*)'s, temp tables, etc.

Anyone know if that would improve the situation or would it still be the same?

To add one to a column, you don't need to select that value, increment it, then update the value. You can just update the value - UPDATE your_table SET your_column = your_column + 1 WHERE ... Oh, I'm not doing that. I am using an update statement exactly like the one you are using. But what I meant is that there are frequent selects on that table to retrieve information.

I have a table with about a dozen columns of data. One of the columns serves as a hit counter. The value is incremented each time with an update statement. So there will be frequent selects and updates which can cause some table locking. If I separate the hits into another table, would that reduce the table locking or would that not really make much of a difference? Now each time the page is visited only the table with just the hits will be updated, but I'd still need to join to that table to display the hits, which I'm wondering will it end up being the same?