DaiLaughing

I know you can JOIN a table to itself to compare two different fields but can't quite see how to apply that (or even if you can). It's first thing in the morning here so my brain is not yet turned on (and I mean really not working). I'll have a look later if I get chance.

DELETE removes the whole of the matching record (row) from the table so I don't understand how the "other data is still there". Also try adding LIMIT 1 to the end of the query just to protect yourself against accidentally deleting every record.

I can only echo ck's comment on that linked page as a whole but the first chunk - on The Adjacency List Model - would seem to be enough of an answer for most people. I have bookmarked the page for later consideration of the nested part (when masochism strikes) so thanks for the link max.

You can't have tables inside tables if that is what you mean. You can use related tables so that every one tweet (?) has one or many users related to it. Is that what you want?

There should be no difference in a cookie just because of where it came from. Have you looked at the actual cookie contents at each stage inside your browser? Another thought is whether the JavaScript is recreating the cookie based on the presence of other cookies or another factor.

I can't tell what you are trying to nest. Tables? Fields? What is in them?

Change the data type or length. Use BIGINT instead of INT for example.

OK thanks both. It is the ON part of the query which defines the structure not the JOINs themselves.

Only in the order of the query words I guess. So how do i create a query that does use the structure in the surgery - doctor - appointment example (where the third table is a child of the second and not the first)? Palm is poised.

If you want access by individual user you could just create a new table and list the pages and access rights for each user or even hard code it into the PHP at the top of each page. Alternatively you could use groups and record the group who has access to each page either in the PHP or in a table. I used this approach as all you have to do is find the groups the user is in and compare them to the groups who have access. Either way you then have another issue - who can see what links to these other pages? If a user does not have access to some pages then do you really want to give them the frustration of clicking on a link and then being told they are not allowed in?

Ticks do help against primitive SQL injection but are easy to get around. That's why I said "supposedly". I should have been clearer that they are not a valid security measure though!

I don't know if there is a speed implication but there is a security one. Supposedly backticks protect against SQL injection where field names are put in by the user (which is rare for - a CMS or PHPMyAdmin need them but I don't go that far with my sites). I must admit I leave them out and hope I will remember to add them if ever the user inputs field names with POST or GET. I did once find myself accidentally using a reserved word as a field name which meant I had to use them as thorpe says but I then changed the field name which seemed a better solution.

I admit my brain is refusing to accept this. Can someone clarify? Using this query on the MySQL world database (http://dev.mysql.com/doc/index-other.html) what relational structure is implied: SELECT * FROM Country LEFT OUTER JOIN CountryLanguage ON Country.Code = CountryLanguage.CountryCode LEFT OUTER JOIN City ON Country.Code = City.CountryCode; The implied structure of the data is that Country is the parent and both City and CountryLanguage are children of that parent: Country / \ / \ / \ / \ CountryLanguage City What concerns me is that the way the query is written partly implies that CountryLanguage is a child of Country and City is a child of CountryLanguage: Country | | CountryLanguage | | City The reason my brain refuses to accept this is the "what if" question of how to deal with a situation where I actually want that three level parent/child structure. For example: Surgery | | Doctor | | Appointment Do I then just change the ON part of the query to reflect that or does the structure of the JOIN part affect it also? I have the feeling that there will be a face-palm moment when someone explains or even when I read my own question tomorrow!

Although there is a more efficient way it might help to split what you want to do into four stages: 1) Use your MySQL query to get both the price and the number of coins the user has (you have this) 2) Use a PHP IF statement to see if the number of coins is more than the price 3) IF they have enough you can take the price from the new number of coins in PHP 4) Use an UPDATE query to change the number of coins in the database This could all be done in one query but leave that for now.

It wasn't meant to sound sarcastic. I'm happy to help or not - genuinely. Apologies if it sounded nasty. The ongoing discussion though shows that we don't have enough info to be sure that what is being suggested will work. As for being respected for my skills and stuff believe me I'm here to learn as much as to help!