19:40まず、Railsの機能として、IDを明示的に指定して保存するのは可能です。保存前にid=(new_id)で値を設定してあげれば、そのIDで保存されます。DBMSごとに、この次にデータを入れた場合の挙動が違うので(42からの連番になったり、自動採番された結果からの連番になったり)、それは確認しておいてください。RailsにおけるDB設計の一般論として、外部システムのIDを自DBのIDとしてそのまま使うのは推奨できません。ようするに自然キーを使うかどうかという話だと思うのですが、少なくともRailsは人工キーを採用することを薦めています。ちなみに、TwitterのIDは、いまと同じようにtwitter_idとして別カラムに保存し、候補キーの一つに留めるのをおすすめします。間違ってintにしてしまうと桁あふれやフォーマット変更でひどい目にあうので、外部システムのキーはvarcharにしておくのが鉄板だと思っています。いうことでこのような時はuser_idを明示的に保存する方法と別カラムにtwitter_idを保存する方法のどちらがRailsとして推奨される書き方になるのでしょうか?に対しては、別カラムにtwitter_idを保存する方法をおすすめします。ちなみに、用語や「でも自然キーでいいじゃない」という議論に興味があれば、Wikipediaの記述がそれなりによいポインタになっていると思います。http://ja.wikipedia.org/wiki/%E4%B8%BB%E3%82%AD%E3%83%BCまず、Railsの機能として、IDを明示的に指定して保存するのは可能です。保存前に`id=(new_id)`で値を設定してあげれば、そのIDで保存されます。DBMSごとに、この次にデータを入れた場合の挙動が違うので(42からの連番になったり、自動採番された結果からの連番になったり)、それは確認しておいてください。RailsにおけるDB設計の一般論として、外部システムのIDを自DBのIDとしてそのまま使うのは推奨できません。ようするに自然キーを使うかどうかという話だと思うのですが、少なくともRailsは人工キーを採用することを薦めています。ちなみに、TwitterのIDは、いまと同じようにtwitter_idとして別カラムに保存し、候補キーの一つに留めるのをおすすめします。間違ってintにしてしまうと桁あふれやフォーマット変更でひどい目にあうので、外部システムのキーはvarcharにしておくのが鉄板だと思っています。このような時は**user_idを明示的に保存する方法**と**別カラムにtwitter_idを保存する方法**のどちらがRailsとして推奨される書き方になるのでしょうか?に対しては、別カラムにtwitter_idを保存する方法をおすすめします。ちなみに、用語や「でも自然キーでいいじゃない」という議論に興味があれば、Wikipediaの記述がそれなりによいポインタになっていると思います。SPAM対策のためのダミーチェックです。表示されていてもチェックしないでください。頂いたご意見への回答は行っておりません。