※注：どこでも通用する話ではない。俺の主観だっつってんだろ。
データという概念と、その周辺の物事についてクソ長文で話す。話す意味はわからない。読んでお前がどう思うかは知らない。
技術の話もするけど、別にエンジニアでなくとも理解はできるんじゃないかい。概念について話していくわけですから。
◆意図
最終的には「オメーらプログラマーども、データの扱い方おかしい」と言いたかった。それを言いたいがためにほぼ関係ない前置きをすげぇ話す。本題は最後にちょっとだけ話す。
そんな感じ。
◆そのへんのデータ
この文章はまずデータであると思う。文章であるし、データであるとも言える。また、俺が昨日みたエロ画像は画像データだ。そして今この文章を読んでいる人間であるところのお前には、情報が付きまとっている。氏、名、性別、住所、生年月日。とかとかとか。
「文章」「画像」「データ」「情報（Information）」という語彙が出てきたわけだが、それらの差は何なんだろか。
ことデータに特筆されることとして、それが「扱われるもの」であるという特徴がある。言い換えると、操作対象であるものがデータ。
※この記事は俺の主観であるということに再度注意しなされ。
データは操作、すなわち保存とか読込とか加工とか送受信とかされる。エロ画像はデータとイコールではないが、エロ画像をデータとして扱うこともできるだろう。
文章を文章として読んでいるときは、それは（狭義の）データではない。が、同じ文章といえども俺がいまPCでシコシコと書いてデータベースに保存したりしている文字列はデータといえるだろう。つまり、そのもの自体がデータであるかどうかというより、それを扱う側によってデータか否かが決定される。
◆デジタル、アナログ、電子、物理
ゼロとイチの集合体のことをデジタルデータ、あるいは電子データと呼ぶ。データといったらまず、すべてデジタルデータである。…というわけでもなく、例えば俺のこの駄文を複合機で印刷してファイリングして国会図書館に保存するとき、データとして扱われていると言って差し支えねぇだろう。
その物理的なデータを複写（コピー）して送付したり、🐐に食べさせたり（デリート）することができる。つまりデータだ。データっぽく操作できるからデータなんだ。
物理データとか言ってるけど、われわれが物理的な空間にいる以上どんなデータであろうと物理的に保存するほか無く、何もかも物理データであると言える。電子は物理的だし、量子力学的とかいう言い回しも聞かないし。ただ、元のデータをデジタル化（？）したとき、それはゼロとイチに変換されて生データとして扱うことはできなくなり、いわばデータを論理的に構成している論理データみたいな感じであるともいえなくもない今日この頃。
くどいけど、🐐はその物理データを食料と思っているから、🐐からしてみればデータではなく食料ってだけだし、そもそもコピー用紙って🐐に食わせていいものなんだろうか。おなか壊しそう。
また、本とは別に、例えば音楽を録音するためのレコードというものがあるよな。あのレコードに記録されているものは本とかと同じくアナログデータだ。物理データ物理データっていってたけど、つまりアナログデータだ。ラジオ放送で音声が聞こえるのも、電波をアナログデータでやりとりしている。
再確認する。デジタルデータはゼロとイチで表現されたりする（離散的な）情報を言う。アナログはもっとこう…ふわふわした…いやウェットな…違うな…うん…。
つまり、レコードに音楽を録音するときって、あの集音部に「チンパンジー！」と叫ぶことによって録音するじゃない？それは、そのまま「チンパンジー！」という音の波をレコードに刻むことで録音してるよな。それはゼロとイチのデータではない。
アナログレコードはそんな感じで、かたやCDはデジタルデータを記録している。アナログである音の波をデジタル化（A/D変換、ADCとかサンプリングとか量子化とか符号化とかそのへん）して保存し、再生するときはそのデジタルなデータをアナログな音波に文字通り再生しているよな。
AM/FMのラジオ放送もアナログ。銀塩カメラもアナログ。フィルムシネマもアナログ。本もアナログ。そして、デジタル音声放送があるしデジカメもあるしDCP（デジタルシネマパッケージ）もあるし電子書籍もあるよね。今はもう見ないけどカセットテープもアナログとデジタルの二種類ある。
オルゴールなんかはデジタルですよね。あの回転するシリンダーにピンがついてて、コームを弾いてるじゃないっすか。あのシリンダーは、音楽をゼロとイチのならびに変換したデジタルデータであるといえる。
音声でも画像でも映像でも、デジタルに変換する規格はいろいろある。ひとつではない。オルゴールに利用できるデジタルデータとPCで利用できるデジタルデータは違う。たとい同じ音楽であったとしてもデジタル化のルールが違うことは普通にある。画像でもjpgだったりpngだったりgifだったりするでしょう。
▼なぜゼロイチなのか
デジタルデータは概ね電気で操作する。その電気って、正or負の2状態だけに絞ってやったほうが扱いやすいんすね。すくなくとも今の技術では。でかいデータ扱うのにでかい電流が必要になるのはコスパ悪いし正確に伝達するのも難しいでしょう。
量子コンピューターは、ゼロとイチよりもっと多くの状態を取ることができるからつよい。例えば、量子コンピューターの扱うデータがゼロとイチじゃなくなって、ゼロとイチとニの3状態になったとする。じゃあもはやデジタルじゃないんじゃないか。…ということにはならない。デジタルはあくまで「離散的」であるということ。2状態であろうと100状態であろうと、その状態が有限個である限りデジタル。つまり、算盤（そろばん）は有限個の珠を移動させて数値を表現するわけだからデジタル計算機だな。
ゼロとイチでいろいろやるブール代数っていうあのアレがあるので、調べてみてもいいかもね。画期的ではあるけどそんな難しい話でもない。
◆保存と読み出しと状態
データは読み出しと保存（Read/Write）の操作が可能である。
例えば、冷蔵庫に貼ってあるホワイトボードに「ばななを二房買って笑いながら食う」という忘れたくないデータをWriteし、それを後でReadしたことがあるはずだ。
その時に何が起きているのか。おかたい表現をすると
- 主記憶装置から外部記憶装置に情報を複製（Copy & Write）し
- 後にその外部記憶装置から主記憶装置に情報を書き戻した。
わけです。主記憶装置というのは脳味噌のことで、外部記憶装置はホワイトボード。
情報を記録するためには、なにかの状態を変化させ、その状態のまま固定させる必要がある。さきほどホワイトボードの表面にインキを乗せ、状態を変えたよな。それで情報の記録（データ化）に成功したことになる。
これが例えば砂浜に書いた好きな女の子の名前であった場合、潮汐によりエフェメラることだってあるだろう。
何がいいたいのかって、データを保存操作にかけるためには「記録媒体」「記録方法」の二要素を考えなければならねぇということ。そして、データごとに理想的な記録媒体というものがある。音楽データはデジタルにしてフラッシュメモリに保存したほうが持ち歩きやすくて便利かもしれないし、好きな女の子の名前が永続化されてしまうとバレて恥ずかしい。
日頃何気なくやっている行為であってもそれは広い意味でデータの操作かもね。脳味噌もデータ処理＆保存の装置に過ぎない。し、脳味噌のみならず人体全体がデータを記録したり処理しているとも言える。話せば長いのでやめとくけど。
状態を変化させる事ができるならデータの保存に利用することができる。脳のシナプスは可塑性を持っているし、リンゴを素手で握りつぶせるのであれば、状態を変えられるのであればそのリンゴをデータの記録媒体として扱うことができる。
そして、データは実質的には状態そのものであるといえる。その、状態であるというだけのデータに意味論的な…っていうとプログラム意味論とごっちゃになるのでそうは言わないけど、データに意味を見出せばそれは情報になる。意味を見出さない限りデータはデータのまま。機械処理されるだけ。
◆「手続き」というデータ
ちょっと技術っぽくしていく。
お前のいま触っている情報端末で、なんらかのデータ操作が頑張って動いていることと思う。とりあえずWebブラウザが動いているだろう。この文章を読んどるわけだし。
Webブラウザが、というかパソコンが何をしているかといえば、データ操作しかしていない。それ以外何もしていない。「データ操作で解決できないこと」はパソコンにお願いすることはできない。逆に、電子データ操作であればパソコンは何でもできる。
データを期待通りに操作するための手続きがわかってさえいれば、そりゃ当然データを操作できるってもんだろう。ゼロとイチのデータを文章に組みなおすことだってできる。
…
いや、「データを操作するための手続き」って、実態として何なんだ？何をすればその手続きを使うことができるんだ？
というので、ご存じ「プログラム」という概念が発生する。
▼プログラム
デジタルデータ（パンチカードとか）を扱うために、電子計算機というものが開発された。コンピュータと呼ばれている。
昔のひとは、「データを処理したいナリ」とよく考えていた。その要望に対して素朴な発想で立ち向かおうとすると、つまり電子の正負をデータとして処理するわけですから、電気回路を組めばいいわけだ。
という考えで電気回路を組みました。計算が簡単になってルンルン気分です。毎日ルンルン気分で計算していたんだけど、その計算に手を加えたくなったらどうする？電気回路を組み替え、新しい電気回路を作らなければならなくて手間だ。また、その便利な電気回路を人に教えてあげたとしても、回路を組むのがとても手間だ。
つら…ﾘｽｶしょ…というので、なんやかんや汎用機＆ソフトウェアという概念が発生した。だいぶ端折ったけど。
汎用機は読んだまま、汎用的に利用できるコンピュータです。回路で作ったコンピュータは専門の処理しかできないんだけど、汎用機はソフトウェア（プログラム）と呼ばれるデータを読み込ませることで色んな作業を任せることができる。
プログラムとは「データ操作命令が記述されたデータ」である。データを扱う方法が書かれたデータ。PCはその命令を…と話し続けようと思ったけどやめとく。話し始めるとこれ際限ない。
最終的には電子データを扱うわけだし、やっぱ電気回路を使うことにはなる。その電気回路をどう動かすっていう根本的な部分（命令セット）はマシンに紐付いていると言っても良い。何言ってるのかわからんかもしれんが。
ハードウェア実装されるプログラムと、ソフトウェア実装されるプログラムがあるということが分かったことと思う。わからなかったか。そうか。まぁそれはどうでもよい。ハードウェア実装よりもソフトウェアが完全に有利…というわけではなくて、同じ処理しかしない場合はハードウェア実装のほうが無駄がなくて計算コストが超有利なんです。近頃（むかしから）ですとFCOHFPGAという、物理回路をソフトウェアのように簡単に書き換えられるやーつもある。
◆データとインデックス
データにはインデックス（索引）がある。インデックスとはすなわち、データを持ってくるための情報。簡単に言うと、バインダーの背表紙に番号をふるようなものかもしれん。「8番のファイルの20ページ目に一万円札をご飯粒で貼り付ける。」みたいな保存操作ができるだろう。そして、その「8番ファイルの20ページ目」というインデックスを利用してデータを取得することもできる。
なんでデータにインデックスが必要であるのか。それは機械的に処理するためです。場所を指定できなければデータを引き出せない。
プログラミングにおける変数は、つまり変数名というインデックスをデータに付与しているようなもんである。
◆DBとStorage
データベース（DB）というものがある。データを入れておく基地。
エンジニアという人間は「データを扱う」という一点のために色んなことをやっている。そんなんだからデータを貯めておくシステムがとても大事。
DBには種類が色々ある。リレーショナル・データベースというものや、KVS（キーバリューストア）というものがある。無論それだけではなく、エロ画像をPC上で扱うために「ファイルシステム」というものがあって、それもある種のデータベースと言えなくもない。
なにかシステムを構築したいとき、兎にも角にもデータを保存する必要がある。データが保存できなければ、まさしく何もできない。そいでさっき話したみたいにデータを保存する仕組みが色々あるけども、どんな仕組みを使おうとデータはただデータベースに入っていて、処理に使用される。
▼揮発
揮発データと永続データ（不揮発データ）って区分がある。揮発データは、システムの電源が消えたら一緒に消えちゃうデータ。永続データはシステムの電源を切っても残るデータ。データを永続化したいときに保存する場所のことは「永続化層（Persistence layer）」って呼ぶです。例えばゲームを遊んでるときは、その進行具合が揮発性メモリに保存されている。セーブをしたら不揮発性メモリに保存される。2020年現在、揮発性メモリのほうが読み書きを高速に処理できるんだけど揮発しちゃうのがネック。容量あたりのお値段も高い。
ポケモン金銀のセーブが効かなくなるのは、カセットに入ってるボタン電池の電源がなくなってレポートが揮発しちゃうから。あれは揮発性メモリに保存してんですね。
何を永続化するべきで何を揮発させるべきかっていうことを考えろ。そのデータは本当に永続化させなければならないものだったのか？揮発してもなんとかなるデータをなんとなくで永続化させてしまうと変なことになるよ。
◆データの設計
※愚痴
プログラマーと言えば、お前らはなんか黒い背景に英文字をビビッドな色で浮かべて暗い部屋でメガネかけてニヨニヨしながらキーボードカタカタいわす職業と思ってる。（被害妄想）
まぁそういう瞬間もあるんだけど、コードがキレイに速く書けたところでさほど役にはたたん（すげぇ役に立つ）よ。それより何よりデータの構造が滅茶苦茶に重要なものなんです。
データが、設計されなければならない。データの形とか関係とか保存場所とか更新方法とか名称が設計されなければならない。
その意識が、少なくとも日本のそのへんのエンジニアに欠けまくっている。データをメインと捉えずにコード（プログラム）を重要だと思っている。それはチャンチャラおかしい。笑わせんな。ヘソで茶をグラグラと沸かしてアナルに流し込んでやろうかボケが。
ゲロ以下のうんちシステムが日本には結構ありふれているんだけど、何よりもまずデータの設計がやっべぇ///ことが致命的にヤッバぁい///💕。クソコードとかスパゲッティコードとか、人の書いたプログラムがヤバいって話もある。あるんだけど、データさえ正しい設計であればなんとでもなるものではある。
けど、ヤバいプログラムを書く人は当然ながらヤバいデータ設計をするものです。
昔はデータの保存方法に技術的な制約があって、ヤバいデータを作らざるを得ないこともあった。
複雑なシステムを組む時にデータの設計をサボると、データが扱えなくなる。機能追加があったときに対処療法的にデータ構造をいじると魔境になる。「根本的に正しいデータ構造」を常に目指さなければならない。
◆インターフェース
どんどん専門的になるけど、これでも掘り下げてないほうだ。というのはどうでも良いんだが。
データは、やりとりされる。マシンAからマシンBに送信されたり、1つのマシンの中でも、1つのシステムの中でも、1つのプログラムの中でもデータはやり取りされまくる。
そういう、データをやり取りする時に「インターフェース」という考え方が発生する。
扉を開けやすい冷蔵庫と、開けづらい冷蔵庫があるだろう。また、パッケージが開けやすいお菓子と、開けづらいまるごとバナナがある。それはインターフェースの問題だ。何かの内容にアクセスしたい時に触らなければならないのがインターフェース。
開けやすすぎると悪い人が冷蔵庫を開けてまるごとバナナを盗み出す可能性もある。データのセキュリティの問題。
通信し合うものどもの間でインターフェースの合意が無いとデータをやり取りすることはできない。インターフェースやデータ設計がおかしい場合、やり取りする相手にいらん迷惑がかかるものだ。
▼データの抽象化
具象データである「ゴリラ」と「人間」は違う。違うデータだ。でも身長っていう同じパラメータを持っている。ゴリラAとゴリラBと人間Aと人間Bの身長を比べることは出来る。
それは、抽象的にデータを捉えているから。
詳しくは説明しない。
◆データの正規化
については話さない。
◆データ構造
データは、単体で成立することはほぼ無い。ここでいう単体とは、例えば以下を指す。
- 数値
- 文字列
- True/False
- 年月日
- 性別
これらは、データとしてはほぼ扱えない。人間というデータは生年月日だけでは表せない。名前とか誕生日とか性別とか、単体のデータを複合して意味を成す。原子と分子みたいなものだろうか。複合されたデータが分子なんだとしたらそれも「単体」と言えなくもないな。
語彙を正確にすると、文字列だとかの単で純なデータ、それ以上分解できない型は単純型（プリミティブ型）と呼ばれ、そのプリミティブ型が複合されたデータを複合型と呼ぶ。
まずそれが1つ。
▼データモデル
学校というものをデータに落とし込もうとした時、学級「3年B組」というデータがあり得たとする。その時、3年B組の生徒「山田太郎」くんは学級の子データであろう。また、「3年B組」も「3学年」というデータ階層の子である可能性がある。（そうしないほうがいい。）
っつーので、データ構造という概念がある。データの関係性のモデルとでも思ってもらえればいい。けど「関係モデル」という名前のデータ構造があったりしてややこしいな。うん。すまん。
そりゃもう沢山のデータ構造があるわけだが、データ構造について話し始めると文章量が爆発する。だから簡単なものだけ。
まず、リスト。いや…リスト…どう説明しよう。言ってしまえば「データを一列に並べたもの」である。トランプってあんじゃん？トランプは「スート4種♠♣♢♡」「ランク13種」が複合したデータでもって「ハートのエース」みたいなカード情報を構成している。そして、ジョーカー抜いたら52枚ですね。その52枚はリストの性質を備えていると言っていい。リストとして扱うことが可能であると言ってもいい。
でも順序のある無しとか、その順序が単方向か双方向かとかある。重複を許すとか許さないとかも。んだもんで、「リストとは本質的に何であるのか？」という話は切り上げる。自分で調べろ。
あとはツリーとかグラフとかスタックとかキューとか色々あるよー（適当）。
▼一貫性
学級というデータについての話に戻る。
「生徒は学級に属している」と思いきや、どのクラスにも属さない流浪の生徒が存在するということに気づいてしまった。そのときどうする？
おまえ「学年に直接生徒がぶら下がってもいいことにしない？」
駄目です。なぜなら、一貫性が失われるから。
データを処理する際に重要なのが、そのデータの一貫性だ。データをプログラムで処理せざるを得ない以上、機械的に読み取りやすい形のデータを作らなければならない。「生徒は基本的に学級にぶら下がるが、学年に直接ぶら下がることがある」みたいなことを信念無く続けると、そのデータは機械的に処理できなくなります。プログラムがエグいことになります。
▼余談：データのなまえ
学年というデータがあったとして、まぁ「1学年」「2学年」「3学年」があるだろう。あるだろうけど、年次をデータの識別子にしてしまうのは悪手。
つまり、一年経つごとにデータをリネームしてやらねばならなくなるのだ。1学年は来年には2学年になる。フォルダ名やらを毎年変えるのはアホらしい。また、卒業していった学年のデータをどう管理したもんだかわからなくなる。4学年になるわけ？
それだと困るんで、データの名称（識別子）は変化しないものを拠り所にするべき。今回で言えば「2020年次入学」とか、入学した年次をキーにできる。
▼余談：更新しない
田中太郎の「テストの平均点」は、データとして持ってはいけない。テストあるたびにそのデータを更新しに行くのはおかしい。「テスト」というデータを積み上げていき、平均点が知りたくなったときは毎度テストのデータを参照して値を算出するべき。
◆見せるためのデータ
人に対して表示されるデータというものがある。わりと多い。
その「表示」ってのが結構に曲者で、エンジニアを散々苦しめてきた。というのも、表示の都合がデータを汚染することがあるのだ。
「モンゴル相撲はたのしいよ。」という文字列があって、それを画面に表示させたいものとする。で、「空白を間に１文字ずつ入れて強調表示させたい」みたいな要望があったとして、「モ ン ゴ ル 相 撲 は た の し い よ 。」というデータを永続化層に保存してしまっていいものだろうか？
駄目です。データはデータなので、表示の都合に引きずられてはならないんです。データはあくまで根源的な情報そのものであるべき。表示の都合があるんなら表示を司るデータが担当せねばならんわけで…（北の国から）
「いいじゃんそのくらい」といいたいかも知らんが、それを許すと際限なくなるんすね。表示のしかたの要望は、表示ルールというデータに分離して固めておきましょうね。
その「表示ルール」をWeb界隈ではCSSという仕組みで分離しておる。かたやHTMLでは静的な文書構造（データそのもの）を表現し、JavaScriptというプログラム言語で動的処理を書く。昔はCSSの機能が全然整ってなくて、表示のルールをHTMLで頑張ったりJavaScriptに書いたりって大変でした。データが表示の都合に汚染される場面が多々あった。保守できないよそんなの。
◆依存してはいけない
表示の話とも関わるんだが、データと、データをやり取りするためのインターフェースはなにかに依存してはいけない。
あるシステムにしか利用できないデータは価値が低い。し、あるプログラムにしか利用できないデータも価値が低い。他の利用方法を考えた時に、依存関係が強いと大変な手間が発生する。
プログラムの中の「ある関数」にしか利用できないデータも価値が低い。低い上にコードの可読性を損なう。システム間だけでなく、関数間のデータのやり取りにも神経を使うべきである。
データがデータとして純粋であれば二次利用が簡単になる。他のとこでの使い易さを「可搬性」という。また、結合の具合は「疎（依存性が弱い）」「密（依存性が強い）」と表現される。疎結合とか密結合とか。「それすると密になりすぎるんで駄目です」という話をエンジニアはコロナが流行る遥か前からずっと話していた。
◆データは更新しちゃ駄目
データを上書きするのは、駄目。特に他からもらったデータは絶対に上書きしてはならん。もらったもの全部を貯め続けるべきです。
上書きするのの何がやばいかって、何を上書きして何を上書きしてないのかがわからなくなるし、上書き前のデータを参照できなくなる。なんかあったときに元の状態に戻せなくなってしまう。
データを更新するなと言ったけども、往々にしてデータは更新されるものである。そのほうが楽だし。ただ、データを扱うための戦略をちゃんと立てておかないと後悔すんぜと言いたい。
データの上書きを極限に避けようと思った場合、「何が起きたか」というイベントの積み重ねから現在の状況を算出することになる。ブロックチェーンがちょうどそれ。
▼ライフサイクル
データには作成タイミングとか更新タイミング、削除タイミングがある。なんらかの複合データが有った時、その複合データが持っている各データのライフサイクルが一致するかどうかについて意識しとけ。
例えば、ある荷物を送るための伝票データがあったとして、オメーらが良くやりがちなのが「空の伝票データ」というデカい複合データを作成してしまうやつ。
- 荷物を送った時に「配送依頼日時」を更新
- 荷物を業者に渡した時に「受け渡し日時」を更新
- 相手が荷物を受け取った時に「受け取り日時」を更新
- 返品された時に「返品依頼日時」を更新
みたいなことをするんでしょう。それはライフサイクルがあってないです。伝票のIDに紐づく「配送依頼」というデータとして分離しなはれ。
ライフサイクルの合致しないデータを安易に複合してはいけない。分離して関連させなはれ。
※なぜかと言うと、データが扱いやすくなるからです。
- RDBであれば各SQLの影響範囲がわかりやすい。
- 障害があった時にリカバリ対象を絞るのが容易になる。
（レコードが更新されたかどうかよりも、レコードが作成されたかどうかのほうが見通しがいい） - 例えば「配送依頼」に業者情報とか紐付けたくなった時にわかりやすい。
- nullを扱うケースが減る。
（逆に言えば、nullが登場しまくっているシステムはデータ設計がおかしい。）
とか。
▼主導権
データの主導権について意識しやがれ。誰にでも書き換えられるデータは、状態がワケわからなくなる。船頭多くしてデータがこわれる＾～。にゃ＾～。バケツリレーなどもってのほかですよ。誰がデータを生成するのか、誰がデータに責任を持つのか、誰がデータを配信するのかをしっかりと絞れ。
各システムが自由にデータを書き換えるのでは収拾がつかなくなる。だから「データを作成/更新したから受け取りなさい！このメス豚が！」「最新のデータをよこしやがりなさい！このメス豚が！」「データをあなたの手で更新しなさい！このメス豚が！」という命令のやり取りで協調して動くようにしなさいこのメス豚が。
システムとは言ったが、プログラミングでも同じことが言える。JavaだのC#だのでオブジェクトを扱うことになると思うんだが、そのオブジェクトの主導権やら、オブジェクト自身の責務について思い馳せろ。
◆算出
ある人間を記録しようとした時、その人間の年齢をデータベースに保存するべきだろうか。
しなくていいです。生年月日さえわかればいいから。むしろ年齢を保存してしまうとそのデータを毎年一回更新せねばならなくなる。アホらしい。「年齢」というデータにできそうな概念の本質は、生年月日と現在の日時の関係性にすぎない。
◆ID
すべてのデータには、それをそれと知ることのできる一意の識別子を設定しないと後悔することになりますよ。データのやりとりをしようとした時につらみが発生する。どんなデータにも、そのデータの生成者がIDをふるべき。
画面でIDを作るな。バックエンドで作るかDBに任せれ。
◆冪等性
「トグル保存」という処理を考える。
- 「ON」というデータを保存していた時に「OFF」で上書き
- 「OFF」というデータを保存していた時に「ON」で上書き
この処理は、冪等性が無い。この処理を呼んだ時に結果が不定となるからだ。つまり、データの状態に因って処理結果が変わってしまう。
つまり、データ操作がデータに依存してしまうということ。何が困るって、いまはON/OFF切り替えっていう単純な話だったからいいんだけど、込み入った処理になると、その処理に因って何が起きるのか人間には想像できなくなってくる。
データ操作をデータの状態から分離しなければならない。今回で言えば「OFFにする処理」「ONにする処理」というふうにインターフェースを2つ用意するのが正解。
◆並列処理とデータの順序
潔癖な思想で作られたデータは必ず並列処理できる。クソデータは並列処理しづらかったり出来なかったり。
🍞が2斤あって、太郎と次郎がいると思えよ。その🍞を食い切りたい時、人間がそれぞれひとつずつ🍞を食えば済む話だよな。それが並列処理。状況により分散処理とも呼ぶ。
ただ、「🍞Aを食い切ったあとに🍞Bを食わなければ、三郎がふみ江に呪殺される。」という前提条件があった場合、🍞Aの処理を待ってから🍞Bの処理を開始せねばならなくなる。2倍の時間がかかる。
その「前提条件」はつまりデータの事情だ。データの設計が悪いと並列処理をする目がなくなってしまう。データが順序に依存すると処理に余計な時間がかかる。バッチ処理に6時間とかかかる。ちゃんと設計してたら15分で済んだものをよ。
順序とは関係ないけど「🍞Aは太郎が食わねばならず、🍞Bは次郎が食わねばならない。」みたいな依存もありうるよね。必要な依存と不必要な依存を切り分ける目を持とうよ。
◆結論
といったふうに、データって奥が深いものなんです。
書くの疲れた。
みんなもデータと友だちになろう（超適当）
コメントを残す