ｽｸﾚｲﾋﾟﾝｸﾞしMYSQLに書き込む方法を聞きたいです｡ http://q.hatena.ne.jp/1434818671 続き｡ｽｸﾚｲﾋﾟﾝｸﾞに関して､ご回答が大変参考になりました｡ phpも捨てきれ…

ｲﾒｰｼﾞがわかないのですが､見比べる方法が必要なのでしょうか｡

なければ登録､という時はどうしても既にあるかどうかというﾁｪｯｸは必要になります｡

もっとも厳密であろう方法はすべての項目を比較というか､一致するﾚｺｰﾄﾞが存在するか確認する方法です｡
http://mislead.jp/1025.html
上記はPHPですがざっくりとはこんな感じかなと｡ただ､値は直じゃなくﾌﾟﾚｰｽﾎﾙﾀﾞを使います｡
http://d.hatena.ne.jp/takehikom/20080623/1214170792
https://rubyist.g.hatena.ne.jp/yumimue/20071031/1193816175
rubyで詳しくだとこんな感じ？

SELECT * FROM ﾃｰﾌﾞﾙ名 WHERE ｶﾗﾑ1=? AND ｶﾗﾑ2=? AND ...

これで有無を判定して､なければinsertで追加｡
ただ､これ1秒に何度も呼ばれる可能性のあるWebｱﾌﾟﾘとかだと重いのでどうにかして避ける事を考えます｡
今回はﾚｺｰﾄﾞ数も何万とあるわけではないし､cronでたまに回すだけだから､負荷は上がっても多分大きな問題は起きない気がします｡

とはいえせっかくだし､DBには便利に使える仕組みがあるのでそれ使う方法も考えてみます｡
http://q.hatena.ne.jp/1434818671#ac113090
この辺でa-kuma3さんが書いてますが｢ﾌﾟﾗｲﾏﾘｷｰ｣というのが何度か出てきます｡
これはDBに登録された1件1件の記録(ﾚｺｰﾄﾞ)を特定するための項目を差します｡

質問ﾃﾞｰﾀは､質問番号がﾌﾟﾗｲﾏﾘｷｰなんですけど

このばあい､1434818671とか1436077068とかが質問番号で､これさえあれば人力検索での質問が特定出来ます｡
つまり､全ての項目を見なくても同じ質問か分かるし､この番号が既に登録されていれば質問ﾃﾞｰﾀが登録されている事が分かる､ということです｡
ただ､更新がないとか常に最新に更新とかの場合は簡単なんですが､そうでない場合はｺﾒﾝﾄにあるように工夫が必要になったりします｡

さて､今回の場合は､更新があった場合､更新前のﾃﾞｰﾀはそのままに､新たに1件記録するわけですね｡
で､問題は何をもって新規とか更新とかを判断するかですが､一番それっぽいのは更新日時ですね｡
前提としてまったく同じ日時での更新はないと仮定します｡
するとこの日時で登録あれば既に登録されているし､内容が変わったなら別の日時になる､という事になります｡
ただ､それは｢まったく同じ日時での更新はないと仮定｣した場合です｡もしこれがあると同じ日時の記録は同じ内容と判断されどれか一つだけ記録される事になります｡
それを回避するには更新日時に加えて他の項目も加えます｡といっても今回の場合､確実にそう保証出来るものはないというか､結局は全部比較して……みたいな話になってしまいますので､妥協点として発生日時＋更新日時もしくは発生日時＋都県名＋更新日時でどうかな？って思います｡

これらの項目をﾌﾟﾗｲﾏﾘｷｰにしてやることで､それらが重複したものは記録で着なくなる＝単純にinsertしてﾌﾟﾗｲﾏﾘｷｰによるｴﾗｰは無視すればOKになります｡
ﾌﾟﾗｲﾏﾘｷｰについては以下とかでどうでしょう｡
http://northqra.com/table_3.html
http://mysql.akarukutanoshiku.com/category6/entry30.html
複数ｶﾗﾑにも設定出来ます｡
http://www.dbonline.jp/mysql/table/index8.html

というような所でどうでしょうか｡

以下予談
上記で妥協があったり､ｽｸﾚｲﾋﾟﾝｸﾞとかの場合､書式が変わったりｴﾗｰになったりで記録できていない事はよくあります｡
恒久的な事もありますが､例外的な記述のために数日間だけごっそりない､元ﾃﾞｰﾀは既に更新済みとか､cronで回してるとありがちです｡
なので､容量に余裕があれば､取ってきたﾍﾟｰｼﾞ内容をhtmlのまま､それ様ﾃｰﾌﾞﾙに記録しておくとかするといざと言うとき助かります｡
＃その時は取得日時も記録して90日とか容量にあわせ一定期間で消しておいたほうが良いです｡
＃それで容量食いつぶして本来の記録がｴﾗｰになるとか本末転倒なんで｡
あと､最初のうちは何件登録したとか概要を標準出力に出すようにして､ﾒｰﾙで確認しとくとか｡