データ格納の今後について考える前のおさらい


コンピュータシステムのデータ格納
⇒これまでも、今現在もリレーショナルデータベース(RDB)が主流

現状がどうなのか自分なりにまとめてみた。

■DBMS格納以前やRDB使うまでもない/データ移行時
⇒ファイル格納 [ バイナリ / テキスト ]
– 利点
分かりやすい[ファイルが実体 / テキストならば人間でも読めるしいじれる ]
設定ファイル等DB格納するまでもないデータに適している
– 欠点
業務データの場合は、複数同時編集が出来ない (差分同期とか考えると狂気の沙汰)
データが大きい場合、端末×データ容量と各端末に格納領域が必要になる
副次的にメンテナンス (データの入れ替え) が困難
________________________________________________

上記のような欠点を克服したのがデータベースシステム
データベースは単純には、1プロセスがファイル(単一/複数は内部実装として意識する必要がない)を扱ってくれるシステムから始まっている。
⇒都合、マシン間通信ないしプロセス間通信となる。

共通的にデータを扱えるSQLと言う言語で、表形式のデータを扱うのがRDB
SQLiteは管理システムではないが、SQLで表形式のデータを扱えるファイル格納の開発手法をDBMSと同一にすると言う思想のコンポーネント

■リレーショナルデータベース(RDBMS)
– 利点
端末各々にファイル格納より大きなデータを扱え、リソースを集約できる
複数人で同一データを編集可能
トランザクション処理という概念を持ち処理一貫性の仕組みを持つ
SQL標準というデータ入出力のための統一化された仕様を持つ ( SQL標準に従うとDBMSを変えても基本は方言を変える程度 例:SQL Server ⇒ Postgress )
– 欠点
ロックやトランザクションとファイル格納に比べて使用側(開発側)が意識すべきことが多くなる。
表形式という縛り (データ格納の自在度) ⇒XML列を使う口が増設されている

データ構造が表形式というのが最大の欠点?
⇒ XML DB / オブジェクト指向 DBと亜流的な流れはあるが、いかんせん複雑で普及に至っていない? (設計も開発も汎用的すぎると大変)
表形式という単純で、トランザクションとロックと処理コストさえ考慮すれば難しくない構造は利点とも言える。

トランザクションにより発生するロックは複数処理の排他ロックの概念そのものなのでマルチスレッドでリソース扱うときと
同様どのようにリソース共有するかと言う話程度

開発手法に限って言えば
オブジェクト・モデルとリレーショナル・モデルのデータ構造の違いから「インピーダンス・ミスマッチ」が問題にされる。
リレーショナル・モデルとは何か?という話を始めると長いので上記単純化した話の流れからいうと、
プログラム側でオブジェクト指向という流れが主流となり保守性 (仕様変更への耐性や部品の交換) に効果があると認められ普及していくなかで相反するリレーショナル・モデルと齟齬が生まれている。

ではどうするか?O/Rマッパーを使おう!と言うところでほぼ現在の状況の一歩手前に至る。
かなり端折っているがO/Rマッピング自体にも批判があったりDBMSと言うデータ格納そのものを変えようという試みがあったりという状況

O/RマッパーでC#だったらADO.NET Entity Frameworkでも使おう。
リレーションしているテーブルからEntityをマッピングしてうまく拾ってこようというのが基本概念。

このあたりの開発を意識したことない人でも、ボタンクリックイベントでいきなりSQLアクセスせずにデータアクセス用のモジュール (クラス)ぐらいは作って使っているのではなかろうか。

開発回りまで話が逸れたが、色々な方向性があるものの確定的でなく現状RDBMSは主流の地位にあるという話。

カテゴリー: 雑記, 設計 タグ: パーマリンク