菊池です。

フォローしてくださった皆さん、ありがとうございます。

自分が勉強不足ということを改めて実感したしだいです。
何とかなるものですね。ほんとに感謝しております。

開発メンバと相談して最終的の方式を決めたいと思います。

また、基本的な質問をするかもしれませんが、今後ともよろしく
お願いいたします。


05/12/05 に そめえだ<someeda@g...> さんは書きました:
> > このような感じでしょうか?
> > もしOkでしたら、実はこのようにしたいと思っていました。
>
> そんな感じだと思います。
> やはりこうしたいと思いますよね。> 菊池さん
>
>
> > お伝えしていなかったのですが、今回のシステム仕様では、
> > 上記２つのテーブルを定期的に全削除して、全登録するという
> > 運用があります。こうしてしまうとidの部分がauto incrementされてしまい
> > テーブル間の関係が崩れてしまうと危惧しています。
>
> ＃検索のためのテンポラリデータベースみたいな感じでしょうか。
>
> ちょっと実験してみました。
> 全削除後に一件づつ insert する時に、create を使うと、id を指定しても
> auto incrementされてしまいますね。
> しかし new して作成したインスタンスに id を指定して save すると
> id がちゃんと反映されました。
> こういった挙動でしたので、後者の方法で全て id を指定して insert し
> 後で DB の auto increment カウンターを適切に設定してはどうでしょう。
>
> 解決のポイントとしては、データのリレーション関係が保存されていれば良い
> と思いますので。それさえしっかりしていればいろんな方法がありそうですね。
>
> 例えばですが、社員テーブルにデータダンプ時にのみ使用する
> 部署コードフィールドを作っておきます。普段はこれは使いません。
> 仮にこれを shain.busho_code なんていう名前にしましょう。
> データを全削除する時に、このフィールドにbusho_codeを転記しておき、
> 次に全登録する時にはこんな手順でしょうか。
>
> ・部署テーブルをまず登録。新しいIDが確定する。
> ・社員テーブルを、転記した busho_code を手がかりに新しいID
> を shain.busho_id に登録。
>
> 思いつきで書いてしまいましたが、実際はダンプしたデータを見れば
> shain.busho_code なんてテンポラリ的なフィールドは不要ですので。
> 実際にどうするかは、全削除してから再構築するまでに何が起こるのか
> によって決まってくる気がします。
>
> --
> ---------------------------
> そめえだ
> http://someeda.mydns.jp/blog/
> someeda@g...
>
> --
> ML: rails@r...
> 使い方: http://QuickML.com/
> Web Site: http://wiki.fdiary.net/rails/
> ML Archives: http://www.fdiary.net/ml/rails/
>


--
bulldog <bulldog@t...>
web :    http://thanks-gunpla.com
blog :    http://blog.thanks-gunpla.com
search: http://gungle.tk

--
ML: rails@r...
使い方: http://QuickML.com/
Web Site: http://wiki.fdiary.net/rails/
ML Archives: http://www.fdiary.net/ml/rails/