そう、某SNSでid=1をユーザアカウントとして利用していたのですが、規模がでかくなるにつれてこのid=1ってのがいろんな意味で辛くなってきたのですね。
具体的には、招待じゃなくって自分で新規登録してきた場合に繋がっちゃうっていう点が一つ。そして、サイトの管理者としての発言と、サイトの参加者としての発言が混ざってしまう。この2点が大きかったりします。じゃー、新しくメンバーをつくって、それで個人の活動をすればよいってわけですが、今まで書いたデータとかを残しっぱなしにするのがもったいないなぁ、となるわけですよ。
で、やってみましたアカウントのデータの移動。以下、備忘的に記録です。備忘的なので、これを参考にしても何が起きても知りませんからねー。
1.現メンバーのメールアドレスを変更
2.新メンバーを作成、c_member_idを確認(Xとします)
3.各テーブルのデータを移動
### 日記データupdate
mysql> update c_diary set c_member_id = X where c_member_id = 1 ;
### 日記のコメントをupdate
mysql> update c_diary_comment set c_member_id = X where c_member_id = 1 ;
### 日記のコメントログ（？）をupdate
mysql> update c_diary_comment_log set c_member_id = X where c_member_id = 1 ;
### コミュニティのトピックをupdate
mysql> update c_commu_topic set c_member_id = X where c_member_id = 1 ;
### コミュニティのトピックのコメントをupdate
mysql> update c_commu_topic_comment set c_member_id = X where c_member_id = 1;
### レビューをupdate
mysql> update c_review_clip set c_member_id = X where c_member_id = 1 ;
### レビューのコメントをupdate
mysql> update c_review_comment set c_member_id = X where c_member_id = 1 ;
### 受信メッセージをupdate
mysql> update c_message set c_member_id_to = X where c_member_id_to = 1 ;
### 送信メッセージをupdate
mysql> update c_message set c_member_id_from = X where c_member_id_from = 1 ;4.入ってるコミュニティについてはid=1に残したいものもあったので､手動で変換。でも、よく考えたら残すのは数個で、残り数十については完全移動だったからSQLたたけばよかった、、、。なんか、管理者とかあってテーブルがやっかいっぽいと思い込んでた、、、
以上が、私がやった作業ですね。他にもc_member_idが含まれているテーブルはあるので、利用に応じてupdateが必要になります。