ここに書いた、ファイルをどこにどう置くかという戦略について。
■なぜ、そんな戦略が必要か
FlashやJAVAScript、Javaのアプレットを利用したプログラムの場合、参照・更新できるデータがある場所というのは、（セキュリティ上）限られている。ローカルのファイルを、基本的に更新・削除できないなど。
また、ケータイの場合、ＢＲＥＷは、そんなに容量的な制限を感じないかもしんないけど（なことない？）、iアプリなどでは、容量的な制限があるかもしんない。
てなことで、データをどこにどのような形で置くかということを考えないと、システム的な処理スピード上、問題が出ることがある。
たとえば、商品コードを入れたら、商品マスタを参照し、単価を表示するといった場合、商品マスタがサーバ側にあると、必ず、サーバー通信が入る。そうすると、商品１件ごとにサーバーと通信しないといけなくなり、入力が極端に遅くなって、実用にならなくなる。
このようなことを避けるために、データのおき場所戦略が必要になる。
■戦略の立て方
戦略には、次の３ステップがある
第一ステップ：どこにおけるか考える
第二ステップ：どんなデータがあるか考える
第三ステップ：どんなデータをどこに置くかを考える
今回は、まず第一ステップについて考える
■第一ステップ：どこにおけるか考える
データを、どこにおけるか、そしてどうやってアクセスするか考える。
この場合、今回、話題がクライアントなので、クライアントを中心に考える。
なお、ここであげた置き場所は、考えられるものを挙げただけで、実際の場合は、この中にも使えないものがある（ケータイの場合、環境変数って？のように）
おき場所
（１）サーバーにおいて、サーバー通信で取得する
サーバーに、ファイル、ＤＢ，プロパティファイルの形でおいておき、サーバーと通信することによって、値を取得する。一般的な方法である。
クライアントの立場から考えているので、サーバーでは、どんな形（ファイルかＤＢか）ということは問わない。とにかく、サーバーにあるものは、クライアントは通信して取ってくることになる。
（２）クライアントの環境変数
クライアントの環境変数の中に入れる。
一般にこの場合は、
・複数のアプリで利用するもの
・（後述の各プログラムの）プロパティファイルのありか
を入れておくのがいい。なんでも環境変数にいれてしまうと、バージョンごとの競合が起こったり、予期しないアプリ同士の名前の一致で変な動きになったりする危険があるので。
（３）プロパティファイル、INIファイル
クライアントの中にあるプロパティファイルや、INIファイル。
クライアントのプログラムごとに、独自のデータを入れとくのに都合よい
（４）クライアント側のファイル、ＤＢ
クライアント側にファイルを持つ。もてないものもある。
制約は、いろいろある
また、BREWの場合、IDATABASEを使って、クライアント側にＤＢっぽいものももてる。
ある意味、ケータイのアドレス帳もＤＢとみていいだろう。
（５）プログラムの中に埋め込み
短いコードなどでありえるのだが、プログラムの中にコードとして埋め込んでしまう。
たとえば、Webアプリの場合、性別：男、女は、これ以外、普通ないので（ということにしておく）
＜Select name=seibetsu size=1>
＜option value=1＞男＜/option＞
＜option value=2＞女＜/option＞
＜/selected＞
としてしまって、もう、男、女を１、２で返すものと、ＨＴＭＬファイルの中で埋め込んでしまうのもありだ。星座、血液型、都道府県、などなど、この手は結構いっぱいある。
Javaの場合は、static finalの形、Ｃなどの場合はdefineにする。
（６）データを返すアプリをつくる
あんまり言われないけど、こーいうことも考えられる。
アプリ側で、値を返すアプリを作ってしまい、そいつを呼び出すということだ。
これが、サーバー側にあると、ＳＯＡということになる。
（７）外部から
ＱＲコードやＩＣタグなど、外部からデータを持っているものを取り込むケース。
現在は、コードのみだが、ＱＲコード等の場合、データだけでなく、商品名、単価を持つことも、可能である。
■実際には
実際には、ケータイの場合、
（１）サーバー、
（４）ファイル
（５）プログラム埋め込み
（（６）データを返すアプリもあり？）
（７）外部から
が利用可能であり、
JavaScriptの場合、
（１）サーバー、
（４）ファイル（読み込み）
（５）プログラム埋め込み
が中心となる。
っていうことで、今回はおしまい。続きの「第二ステップ：どんなデータがあるか考える」については、また気の向いたときに。
アクセス
トータル
ランキング
