飛行機にユニークIDはない プログラマーが知らない航空の誤解

たぶん、プログラマーとして航空関係のソフト書く時、『こういう前提でいけるっしょ！』って思うじゃん？残念ながら違うんだな〜。ソフトは厳密なルールで動くから、現実を全部カバーできるルールを見つけるのが大変なんだよ。例えば、DBのスキーマでフライトに『出発空港』と『到着空港』があるって考えるの、自然だよね？でも、残念！

俺がもっと言いたいのは、システムをモデル化する時って、そのモデルのほとんどが実は『仮定』なんだよってこと。だから、DBのスキーマとかも、それが自然に見えても、実は間違ってるかもしれない仮定の上に成り立ってるわけ。特に人間が直接関わるシステムだとね。全部のケースをカバーできるルールなんて、そうそう無いんだよ。『どんなアホでも大丈夫なように作っても、それを超えるアホが出てくる』って言うだろ？

で、だから俺はDBの主キーに、現実の値（ナチュラル値）じゃなくて、システムが勝手に作る値（サロゲート値）を使うのが好きなんだ。サロゲートでも、連番じゃなくてUUIDを使うようになったのもそのため。この記事みたいに『この値はユニーク』とか『この値は変わらない』って思い込み、だいたい間違ってるじゃん？だから今は、DB設計する時も『全部変わる、何もユニークじゃない』って前提で考えるようにしてるんだ。専門家が『絶対ユニーク！』って言ってもね。このやり方、後々『あのキー、ユニークじゃなかった！』ってなった時の手戻りがなくて、マジ助かるよ。

君のそのやり方（UUIDをPKにすること）で失うのはパフォーマンスだよ。DBの種類やテーブルの大きさによるけどね。1000万行くらいの小さいテーブルなら気にならないけど、数億～何十億ってなると、ハッキリ差が出る。UUIDはBIGINTの倍くらい大きいから、インデックスも倍になるし。v1かv7じゃないと並び替えも大変。それに、特にMySQLなんかだと、ユーザーの購入履歴みたいに同じものに関連するデータが、DBの中でバラバラに置かれちゃうんだ。それがデカいテーブルだとデータの読み書き（I/O）がめっちゃ増える原因になる。カバリングインデックスとかでごまかす以外、改善は難しい。PKを（ユーザーID、別のID）とかにしておけば、同じユーザーのデータが固まって配置されるのにね。

サイズは関係あるけど、100億行のサイズと比べたらインデックスの8バイトなんて多分大したことないでしょ？SQL Serverはどんなインデックスでもクラスタリングできるから、ParentGuidでクラスタリングすると子テーブルが得するならやればいいじゃん。

MySQLは全てのセカンダリインデックスにPKのコピーを持つから、結構サイズ増えるよ。100億行のデータ全体よりは小さいだろうけど、これだけ大きいテーブルならインデックスサイズは重要だと思うな。RDBMS（SQL ServerやOracleはよく知らないけど）なら、ページ内のbinpackingも結果が多いクエリ速度に影響するはず。

でもそれ（サロゲートキー）はシステム内にしか存在しないから、外部から「この飛行機で何かあった」って情報がきても、システム内でどのサロゲートIDか探すのが大変だよ。外部では同じ飛行機なのに自分たちのシステムでは別ってなったり、その逆もあったりするかもね。

UUIDキーは値の変更は楽だけど、履歴管理は解決しないよ。UUIDキーに作成日付きのバージョン管理を組み合わせれば、空港名を変えても過去の特定日に何て名前だったか分かる。データの後処理とかデバッグに便利だよ。

そんな色々いらないよ。ナチュラルキーでもそれにdatetime足せば十分。あるDatetimeより前の空港Xの定義は何だった？それ以降は？って感じで。

でもナチュラルキー自体が変わるものだったら、空港xが空港yに名前が変わったって分からなくなるよ。ただの別々のキーになっちゃう。で、空港の名前を変える時に、その空港名を外部キーに使ってる他のテーブル全部に新しいエントリを追加しないといけなくなるじゃん。

＞ でもナチュラルキー自体が変わるものだったら、空港xが空港yに名前が変わったって分からなくなるよ。
そう、だからいつ有効かのDATETIMEが必要なんだ。＞ 他のテーブル全部に新しいエントリを追加しないといけなくなるじゃん。
いや、名前じゃなくてICAOみたいなコードをキーにすればいいんだよ。そして外部キー制約を使う。
例えば、物理的な空港、コード、名前を別のテーブルにして、それぞれ有効期間を持つ設計（SQL例はコメント見てね）。こうすればJFKみたいに名前やコードが変わった歴史や、コードが再利用されたケースもモデル化できる。サロゲートキーより簡単じゃないけど、人間には分かりやすいし、飛行中に名前が変わるようなケースも対応できる。一番大きいflightテーブルからはicaoと日時でリンクできるんだ。

これは「地図と領土」を混同する典型的な例だね。地図上では「飛行機」や「空港」は明確だけど、現実（領土）は曖昧で例外だらけ。期待する関係は驚くほど破られる。これは航空業界だけじゃなく、どんなシステムも現実と抽象モデルの違いに苦労するんだ。

俺たちプログラマーは、物事を厳格なルールに落とし込むのが好き。それが頭の動かし方だからね。確率的な「アナログ」なパラメータは少ない方がいい。もちろん現実世界はそうはなってないけどさ。

＞ それが頭の動かし方だから
それはプログラマーだけじゃないよ。例えばフランス語を学ぶ人に聞いてみて。例外だらけのルールだよ。プログラマーに特有なのは、彼らのツール（コンピューター）がシンプルなルールで最高のパフォーマンスを発揮するってこと。だから彼らは必要十分なルールのセットを見つけて、この記事の例外は扱わないって片付けるだろうね。

例えばフランス語を学ぶ人に聞いてみてよ。arbitraryな例外が多すぎるルール。中学でフランス語取ったけど、先生が最初の5分でルール説明して、その後の40分は例外説明してたのが鉄板ジョークだったな。

俺フランス人だけど、フランス語ネイティブじゃない妻によく「なんでこう言うの？」って聞かれるんだ。簡単なルールと学校で習う有名な例外があるか（それなら妻も知ってる）、もしくは「これはこういうもんだから、ただ覚えるしかない」っていうゾーンに入るか。で、突然、何年か後に、その疑問に答える超難解で obscureなルールがあったりするんだよね。

例外に40分かかるだけでも、それだけカバーできるなら十分良いルールだと思うけどね。

自然言語って、ルールをルールとして覚えてるんじゃなくて、例から学んだりパターンを見つけたりして推測して習得するから、ちょっと変だよね。英語は俺にとって外国語だけど、ルールを学ばずにどうにか習得できたよ。なぜその文法を使ったかは説明できないけど、なんとなく正しく言えるんだ。

結局、データは何らかのアルゴリズムで処理できるように、構造やテーブルに収めないといけないんだ。システムがある程度 Rigidじゃないと、メンテできなくなったりバグだらけになったり、あるいはその両方になるだろうね。

いや、そうでもないよ。ソフトウェアって定義上、扱おうとするドメインのモデルを作らないといけないだけ。で、モデルってのは結局ルールの集合体なんだ。ルールがないと、ソフトは何もできないし、問題を解決する上でも意味がない。代替案は、ユーザーに Notepadを渡して「勝手にやって」って言うことだ。俺は、プログラマーはむしろ、現実世界のドメインにどれだけ多くの例外やエッジケースがあるかをよく知ってると思うよ。例えば、素人に閏秒みたいな単純なことを聞いてみてごらん、でっち上げだと思われることが多いからね。

これらのいわゆる”falsehoods”の多くは、単にプログラマー側の設計失敗なんだよ。誰かが最初に下手くそに作って、それが定着して、後から来た人がその Bad designに驚く。それは別に面白くない、ソフトウェアでは日常茶飯事だよ。だから経験豊富なエンジニアは、そうじゃないと証明されるまで Poor designを予測するようになったくらいだ。
フライト番号に合理的な意味がないとか、Flightという概念が複数の離着陸を含むように汚染されてるとかは、Bad design、単純にそれだけ。問題を正しくモデル化すればいいんだ。例えば Tripは複数の Flights、Flightsは複数の Legsを持つ、みたいに。これは航空業界固有の話じゃない。プログラマーが正しく理解して対処すべき一般的な問題だよ。一部はドメインに固有だけどね。例えば、全てのフライトに Gateがあるわけじゃないとか、空港じゃない場所に降りるとか。それは俺にとって新しい知識だったけど。

主張は、プログラマーがあるドメインについて文字通り誤ったことを信じている、ってことじゃないよ。「Falsehoods programmers believe about X」（プログラマーがXについて信じている誤り）というジャンルの要点は、そのドメインで起こりがちな Bad design assumptionを皮肉っぽくリストアップすることなんだ。そしてそれは非常に面白いと俺は思う。
現実世界のイベントや情報をモデル化するソフトウェアが、そのドメインで何が可能で何が不可能かについて規範的な仮定を置いているのは事実だ。これはソフトウェアの性質上避けられないし、これらの仮定はプログラマーによって意図的かどうかにかかわらず導入されている。もし任意のドメインについて、ソフトウェアの代わりに何百人もの人間の Notaries、Scribes、Typistsが情報を管理していたとしたら、彼らの誤った仮定は大した問題にならないだろう――彼らは単に「あれ、おかしいな」と言って、必要な調整を行い、経験から学ぶだけだ。しかし、ソフトウェアがそれが表現しているものの Prescriptive modelである限り、その作成者が誤って Prescribeしてしまう可能性のある「誤解」を強調することは価値があるだろう。

君の主張が理解できないな。
誰の失敗かは重要じゃないんだ。
この記事の要点は（名前についての記事と同じように）、多くの人が「合理的だろう」と信じる「reasonable defaults」が、実際には通用しない「gotchas」（落とし穴）になるということだ。
それを知る十分な知識があるかどうかは関係ない。多くの人にとってはそれが合理的だと思えるものなんだ。

そしてプログラマーとして、俺たちは必然的にこれらの変なエッジケースの対処にほとんどの時間を費やすことになるんだ。だって、分かりやすい部分は一般的に最初のモデリングに組み込まれて、解決済みの問題になるからね。

「誰の失敗でもいい」なんてことはないよ。航空の誤解なのか、それとも単にダメなシステム設計の誤解なのかは重要だ。俺は航空の誤解の方に興味があるんだ。ソフトウェアが登場する前、パイロットたちはどう考えてたんだろう？ 彼らの概念のどこが筋が通ってて、なんでそれを使ってるんだろう？ その概念からどんな推論ができるんだろう？ プログラマーがそれを誤解するのは面白いんだ。
システム設計が悪くて物事の管理が下手なのは、電車でも工場でも同じで、航空特有じゃないからそんなに面白くないね。ダメな設計ってだけ。どうやら最初の航空システム担当のソフトエンジニアはマジでダメだったらしい。

「プログラマー側の設計ミス」って言うけど、この記事のポイントの多くはプログラミングよりずっと前からあったことだよ。コンピューターが航空で広く使われるようになる前からのものも多い。
確かに、もっと良いデータモデルがあれば最高だよ。でも、それに切り替えるのは、ソフトの問題っていうより、仕組みを変える人間側の努力が大部分を占めるんだ。

航空業界はプログラマーが作ったんじゃなくて、100年以上かけて進化してきたんだ。今の慣習の多くは、航空でコンピューティングが使われるよりずっと前からあるものだよ。決まりごとがないように見えるのは、ただ現実世界がかなりごちゃごちゃしてるから。厳格なシステムを作ろうとするプログラマーは、時々現実世界の人間や出来事が、彼らが作ったルールに従わないことに苦労するんだ。

俺はいつも、この「プログラマーが信じる誤解…」リストをテストを書く時のヒントにしてる。それぞれの項目から、ソフトに間違って組み込まれた思い込みを根絶するのに役立つ単体テストや結合テストがたくさん生まれるはずだよ。

これらは実際にテストになったよ。俺は以前そこで働いてたんだけど、当時テストは千個以上あったんだ。簡単なやつから、あのDavid Blaineのスカイダイビングみたいなすごいテストまでね。そこの連中は、良いエンジニアリングに本当に力を入れてたんだ。

うーん、Blaineのスカイダイビングテストって、どんだけ頻繁に実行できたの？笑

空港コードがどれだけメチャクチャかっていうCGP Greyの素晴らしいまとめだよ → https://www.youtube.com/watch?v=jfOUVYQnuhw
なんでこういう変なところができたのか、詳しい理由（試みだけどね）も含まれてる。

プログラマーについてみんなが誤解してること：
＊本番稼働時に宇宙のあらゆる可能な設定を処理できると思ってる。
＊よく知らないから、本番稼働時に宇宙のあらゆる可能な設定を処理しない。
宇宙についてみんなが誤解してること：
＊定数ってものが存在する。
＊SI unitsは常に、どこでも一定。
…みたいな、誤解リストの誤解版を作ってみたよ。

プログラムについてみんなが誤解してること：
＊新しい変なケースが出てきても、プログラム直すのなんて簡単だ。
…って思われがちだけど、そんなことないよね。

プログラマーに関する誤解についての誤解ってのもあるよね。あのリストに挙げられてる誤解が、実は誤解である（現実には結構あることだ）って思ってる人もいるかも？

この記事のリスト、なんか変じゃない？航空にちょっと興味あるだけだけど、書いてることあんま信じないよ。名前とか時間のリストは、嘘だってわかってびっくりしたのが面白かったのに、これはそうでもないな。飛行機にユニークなIDがないのは別に驚かないけど？所有者が変わったり、改良されたりするのに、安定したIDがある方が変じゃない？

うん、そうそう。このリストってさ、’モデル作る時に単純化しすぎるとダメだよ’ってこと言いたいんじゃない？

これってさ、他の分野でもあるようなエッジケースを集めたリストっぽいよね。プログラマーが車とか船について勘違いしてることの例を挙げてるけど、どんなことでもこういう誤解リストは作れるんじゃない？

＞他の分野と同じように、エッジケースのリストみたいだね。
まさにそれが重要なんだよ。有名な「Falsehoods Programmers Believe About Names」の例は、医療データベースで実際に見かけたことあるし。もしプログラマーが気をつけてたら、患者さんの名前の管理とかもっとマシになってたかもね。https://news.ycombinator.com/item?id=18567548

＞Ships are bigger than boats
俺の知ってる限りでは、シップとボートの違いって高速ターンした時に外に傾くか内側に傾くかで見分けるんだよね。まあ、これもきっと間違ってるんだろうけど、俺の受けた教育みたいにさ。

Submarinesは「boats」なんだよ。ターンでどっちに傾くかって話は、重心と舵の位置関係で決まるだけ。小型boatsは舵が下にあるから内側に傾くけど、Hydrofoilの「ship」も同じ。小型sailboatsだって「boats」なのに外側に傾くこと多いしね。

俺が知ってる船の違いは、shipsはboatsを運べるけど、boatsはshipsを運べないってことだけだな。

でもshipsってshipsを運ぶこともあるよね。それだと、運ばれてるshipはboatになるのかな？

shipsはportsを使うけど、boatsはdocksを使うんだよ。

この記事の別の議論がFlightAwareフォーラムにあるって。ここ見てみてよ:
https://www.flightaware.com/squawks/view/1/7_days/popular_ne…

’飛行機は空港で離着陸’って誤解、ブラジルの昔のシステムはこれで失敗したみたい。ハックで直したってさ。
あと’滑走路は動かない’とか’航空機は滑走路にしか着陸しない’ってのも誤解に追加すべきだね。

ブラジルの古いシステムが失敗したって話、もっと詳しく教えてよ。何があったの？

ブラジルの話は、非公式な着陸帯とか川に着陸することが多いからじゃない？アラスカみたいな場所でも、小さな飛行機が正式な空港以外からも飛んでるから、同じような問題がありそうだよ。

1980年代から航空ソフト書いてるけど、パースペリー・パーリングが使ってたグラマン・マードって水陸両用機が好きだったな。パール養殖のためにキンバリー海岸のどこにでも着陸してたんだ。リンク見てみて。
https://en.wikipedia.org/wiki/Grumman_G-73_Mallard
https://en.wikipedia.org/wiki/Mungalalu_Truscott_Airbase

東海岸だって川に着陸なんてよくあるよ。ニューヨークのイースト川からマーサズ・ヴィニヤードとかに定期便も飛んでるんだ。フェリーから川の真ん中に飛行機が着陸するの見るの、結構クールだよ。

エールフランス447便のこと言ってる？

’航空機は他の目的地にダイバートしたら、もう一度ダイバートしない’って誤解、マジで経験したよ。Aに行けずBに、Bの途中でCに、Cの途中でAに戻ったんだ。結局3時間遅れ。雪と風のせいだったね。

シニアエンジニアでパイロットもやってるけど、この記事のリスト見てちょっと混乱したよ。内容は知ってるけど、なんでプログラマーだけがこの誤解を持ってるって話になってるの？他の航空知らない人たちじゃなくてさ。滑走路番号が磁場で変わるなんてのもあるしね。

コメント9への返信ね。こういう記事は、名前とか音楽とか、常識と違う事実をリストアップするジャンルなんだ。プログラマーとの関連は、こういう事実がDBのキーとかで問題になるシステムを作る時にぶつかるからだよ。