ながい期間、システム構築に携わってきた。
システムは、変わり続けなければならないことが宿命。
ユーザーにとってシステムは便利な器でしかない。
システムを作り、管理していく側から考えると修正するたびに
まったく異なったシステムになる。
理想的なシステムは、日々リファクタリングすることが可能なシステムでしょう。
経営戦略にあわせて、プログラムもデータベースも変え続け、
かつ、過去のデータについても利害関係者に合わせてシームレスに参照できる
ことが理想でしょう。
DOA データベースを中心にシステムを構築していくことで、安定したシステムを作ることが可能ではある。
データベースの構築は、丁寧に業務を分析した上で行わなければならない。
システムとしてリリースした瞬間に、遅かれ、早かれ次の修正が待っている。
データベースの設計は、テーブルの関係性
親子関係、派生関係、参照関係を組み合わせて構成していくが、手作業で行うには
あまりにも複雑で細かすぎる。
特に、旧システムから、新システムへのデータベースの移行は、複雑さゆえに困難を極める。
できるだけ、データベースは変更したくないといった問題は、この辺にある。
データベースは２次元表の塊だ、この塊には業務上の意味づけが関連付けられている。
新システムへはテーブルの修正と、業務上の新しい意味づけが必要になる。
JSONは、１ファイルで親子関係を表現できる。テキストファイルで編集も簡単。
一見、おまじないのようでつかみどころがなさそうなフォーマットだが、
多くのプログラミング言語で読み書きできる。
こちらのPCにあるオブジェクトをネットワークでつながった他のパソコンへ送るようなことにも応用できる。
メモリ上にオブジェクトとして取り込めるので、プログラムで処理してデータベースに書き戻すのも容易だ。
読み込んだオブジェクトをハッシュに入れておけば、さらにプログラミングは楽になる。
データベース <> ハッシュ <> JSON の標準的なパターンを作れば、どんな言語でもシステムの移行は、効率的に進められるでしょう。
XMLもJSONも表現できる内容は同じようなものだが、XMLは、同じ内容のデータを無駄の多いフォーマットで表現することになる。
プログラミング言語ごとに構文解析のパーサが用意されているが方言が多かったり、操作に一貫性がないので、言語ごとにコーディングが大きく異なってしまう。
扱いやすさは、JSONに軍配が上がる。
http://ja.wikipedia.org/wiki/JavaScript_Object_Notation
