ignace

It seems their is "Audit Trails" as found on MySQL forums: http://forums.mysql.com/read.php?20,271696,271699#msg-271699

We need some more information regarding what you are trying to achieve. You can use HeidiSQL if you want to transfer data manually from remote host to remote host or MySQL supports Replication if you want data to be always copied from one database to another.

Copy-pasting won't get you anywhere. If you would have taken the time to look up triggers you would have found that it was missing a ; after the insert statement and you need to specify a different delimiter then the default one. True, but this was the most simplest design I could come up with at the time. Another approach would be the one Wordpress employs each revision is a descendant of the current version as discussed on Wordpress Codex: Revision Management. Are there any SQL patterns for this particular problem? Or better solutions available then the one presented by Wordpress?

It should be noted that it's up to you to implement that only one given person is allowed to edit a specific post at any given time (to avoid 2 people overwrite each others work and both are given a different revision or you could complicate it more and implement merging and conflict resolution).

CREATE TABLE Posts ( post_id .. ); CREATE TABLE PostsRevisions ( post_id .. version .. AUTO_INCREMENT, .. PRIMARY KEY (post_id, version) ); CREATE TRIGGER CreatePostRevision BEFORE UPDATE ON Posts FOR EACH ROW BEGIN INSERT INTO PostsRevision (..) VALUES (OLD.<column-name>, ..) END; This will keep the current revision in the Posts table and available revisions in the PostsRevisions table.

Destroying a specific session works best if you store it in a database using session_set_save_handler. Using this technique also gives you other advantages like ban/log-out a user, in-place access-control editing, ..

Globals are bad as you already knew. Singleton and Registry are globals.

l() is a strtolower() wrapper. a() is a "clever" way not to use an array() $w is thus in the end an array. In summary it shows a known link to certain IP-address possibly spiders who seek for and report hacked websites.

If you link to a website on Facebook it will retrieve one of the images on your website to display as a thumbnail next to the link. Unless you specify an image that should be used instead. <meta property="og:image" content="http://www.onjd.com/design05/images/PH2/WableAFC205.jpg" /> As found on http://developers.facebook.com/docs/share

SimpleXML has the habbit of choking on semi-big files so if you experience time-out's when reading in the XML use XMLReader instead which uses pull-parsing.

Yes You can't retrieve data that isn't send to you by the weather station.

For a news website that allowed it's users to comment on a comment (on a comment ..) the programmer before me used the Adjacency and a recursion function to sort those comments. 2 years later the website had lots of content, lots of comments and lots of users visiting the website daily resulting in a serious load (the analysis tool reported loads till 150%). I completely re-wrote it to use the Closure Table design and load dropped to almost half. Sorting a big result in-memory is NOT a good idea and like you said Closure Table already stores the result sorted which should give you a clue about which design is optimal. I'm not going to discuss this further if you believe Adjacency and Recursion is the way to-go then use it! At least you'll know what to choose when you ever come across the above scenario.

Try that: $fids = fopen('ids.txt', 'r'); $fc = 0; $c = 0; $fsids = fopen('f'.$fc.'.txt', 'w'); fwrite($fsids, "<?php\r\n\r\n"); while($line = fgets($fids)) { // assuming each ID is newline seperated if($c == 20000) { fclose($fsids); $c = 0; // reset ++$fc; $fsids = fopen('f'.$fc.'.txt', 'w'); fwrite($fsids, "<?php\r\n\r\n"); } fwrite($fsids, "\$id_to_save[] = $line;\r\n"); ++$c; } fclose($fsids); fclose($fids);

It seems you do have a BOM issue (look in the upper left corner). This text preceding the HTML tag has the nasty effect of enlarging your font size.

Using file to read out such an amount of lines into memory means you'll need LOTS of RAM (and have it assigned to PHP). A better approach would be to read a "line", process it and continue. $fids = fopen('ids.txt', 'r'); $fsids = fopen('text2.txt', 'w'); while($line = fgets($fids)) { // assuming each ID is newline seperated $line = trim($line); fwrite($fsids, "\$id_to_save[] = $line;\r\n"); } fclose($fsids); fclose($fids); However what you are trying to do won't work, you will never be able to load that file because $id_to_save array would be too massive to load into memory. What are you trying to do quite possibly we can give you a solution that will work.

$fopen = fopen('http://www.maidenerleghweather.com/clientraw.txt'); while($line = fgets($fopen, 16)) { list($nameit, $nameit2, $nameit3, $nameit4, $nameit5) = sscanf($line, '%d %d %d %d %f'); // process }

Deciding whether or not to Unit-Test does not depend on the size of the application but rather on the risk/value of the application. You can have a tiny application that transfers funds from the client to your bank account, you don't want anything to go wrong there, do you? In short apply Unit-Testing for high-risk and/or high-value software. Unit-Testing is like a bug-spray it doesn't guarantee you killed all bugs but the annoyance will be far less

An XSL is embedded in your XML if they ask for XML(y) then you just readfile the particular XML, the browser knows what to do once it receives it. However what kind of data does this XML hold? What's your assumption of the size this would grow to?

Try it yourself: 1) create an average chore list (what do you need to do in a week/month/year?) 2) simulate a list for a 1000 other users 3) simulate these 1000 users actively using your website 4) notice how the load time increases as new users join and load/sort their chore list

Apparently you aren't at all that familiar with Adjacency as the Closure Table is by design created to make these operations easier except insertion. It's true that at first your solution will work wonders until more and more users are starting to use your system, more and more chores are added/deeper nested and your easy recursion suddenly becomes a large bottleneck as your system now only sorts output instead of serving it.

In a Closure Table set-up you sacrifice disk space for performance. Using an Adjacency and sort it in memory is the wrong way of going at it certainly if you know their are structures available that allow you to get the entire tree with minimal effort correctly from MySQL.

SELECT name, count(*) FROM tickets GROUP BY name

c1.feed_id is the root item that will have comments. If anyone has used Google Wave, they have something similar, you can start a wave, then someone can comment your message, and someone else can comment the person that commented you, or they can comment you instead, etc. Using an Adjacency List for something like this won't work because you would somehow have to dynamically write JOIN statements to show all comments, for 3 levels deep you'd write: SELECT ... FROM table t1 JOIN t2 ON t1.id = t2.parent_id JOIN t3 ON t2.id = t3.parent_id .. A far better approach would be to use a Closure Table as explained by Bill Karwin: