DBではない

著者は、醸造業者、DBMS製造業者の浮き沈みについて、そしてアプリケーションを適切に設計する方法について簡単に話しています。 記事の有益な部分は、私にとって有用であるように思われました。



1920年代の米国では、憲法改正によりアルコール飲料の生産、販売、輸入が禁止されていました。 修正は13年後にキャンセルされました。 禁止期間中、ビール産業は死にました。



1933年、禁止が解除されたとき、いくつかの穀物大手がビールの醸造を開始しました。 彼らは市場を完全に独占しました。 そして、ほぼ50年間、私たちはこの炭酸尿を飲んで「ビール」と呼んでいました。 この味に耐える唯一の方法は、非常に冷たい飲み物を飲むことでした。



60代の10代の頃、私は彼の魅力を理解できませんでした。 なぜビール？ これは病気のイノシシの尿から得られる淡黄色の厄介な液体です。 そして、私は単一の重要なプラスを見つけることができませんでした。



1984年に、私はイギリスに行きました、そして、目隠しは私の目から落ちました。 やっと手に入れた。 私は最初にビールを試しました、そしてそれはうまくいきました。



それ以来、米国のビールの状況は大幅に改善されました。 新しい醸造会社は全国でキノコのように成長しており、ほとんどの場合、彼らが作るビールは本当にとても良いです。 苦いほどホップの効いたビールほど美しいものはありませんが、追いついています。



80年代には、いくつかの大企業が自社のデータベースで市場を独占しました。 彼らは、マネージャーやマーケティング担当者に恐怖、不確実性、疑念を植え付けました。 「リレーショナル」という言葉は「品質」と同義語になり、データを保存する他の方法は禁止されています。



当時、私は一流の開発者でした。 私たちのシステムは、T1通信回線の品質を測定しました。 データモデルは比較的単純で、データは単純なファイルに保存しました。 これはうまくいきました。



しかし、マーケティング担当者は、リレーショナルデータベースを使用する必要があると言い続けました。 彼は、顧客がそれを必要とすると言いました。 これは奇妙な願望であるように思えました。それ以来、私はまだ単一のシステムを販売されていなかったため、データを保存する方法に関心を持つ顧客は一人もいませんでした。 単純なファイルは禁止されました。



ソフトウェアの品質を担当する主な開発者である私から見ると、リレーショナルデータベースは大きくて、粗く、遅いhemoです。 複雑なリクエストはありませんでした。 強力なレポート機能は必要ありませんでした。 メモリ内に座って時計をむさぼり食うような数メガバイトのプロセスは絶対に必要ありませんでした。 （80年代だと考えてください。）だから、このアイデアは間違った技術的解決策だったので、できるだけ早くこの考えを打ち負かしました。



私の側では政治的に近視眼的でした。 数か月のうちに、数行のコードを記述したハードウェアエンジニアがソフトウェアグループに移されました。 彼は次第にますます多くの責任を委ねられ、最終的に彼は私の共同管理者と呼ばれるようになりました。 彼と私は、開発チームを管理する責任を「共有」しました。



ええ、もちろん。 そうだね 実際のプログラミング経験のないZhelezyachnikは、チームの管理を「助け」てくれました。 そして最初のポイントは何だと思いますか？ なぜ私たちのシステムでリレーショナルデータベースを使用しないのですか！



1か月後に辞めて、コンサルタントとしてのキャリアを始めました。 それは私がこれまでにした最高のキャリア移動でした。 私が辞めた会社はもう存在しません。 私は彼らが一銭も稼げなかったと思います。



90年代にリレーショナルデータベース市場を見ました。 オブジェクトデータベースやBツリー上のデータベースなど、他のすべてのストレージテクノロジーが縮退して死にました。 20代の醸造家のように。 90年代の終わりまでに、巨人だけが生き残りました。



これらの巨人は波を打ちました。 彼らは神でした。 彼らは支配した。 ドットコムのバブルの間、彼らの1人は彼らのシステムが「インターネットを動かした力」であると主張するテレビ広告を立ち上げる大胆さを持っていました。 70年代のビールのスローガンを思い出しました-「Mnuは私ができるすべての話題をキャプチャする必要があります。」 なんてこった



それから私は、チームがデータベースをシステムの最前線に置いた後、チームとして恐怖で見ました。 彼らは、データモデルがアーキテクチャの最も重要な側面であり、データベースがプロジェクトの核心であるという無限の詐欺によって確信していました。



私は新しい地位の出現を目撃しました。 データベース管理者！ 単純なプログラマーはデータを信頼することはできません。それはマーケティングのナンセンスです。 データは貴重であり、脆弱であり、この訓練されていない田舎者によって簡単に損傷を受けます。 データを管理するには特別な人が必要です。 DBMSベンダーによって訓練された人々。 DBMSの巨人の市場へのメッセージを保護および促進する人々：「データベースは基盤です。 システムの基盤、企業の基盤、世界の基盤、そして宇宙そのもの。 BU-GO-HA-HA-HA-HA !!!」



SQLがシステムの隅々までクロールするのを見ました。 SQLがインターフェースに漏れたシステムに恐怖で叫んだ。 私は、すべてのビジネスロジックをストアドプロシージャに転送することを延々と誓いました。 私は震えながら震えながら、SQLで書かれたメール配布プログラムを読みました。



システムの背後にあるシステムのソースコードにテーブルと行がどのように侵入するかを見て、アラームを鳴らしました。 危険を告げた。 警告した。 このテクニックは、視野のすべてを吸収するアメーバに変わったと言いました。 しかし、私はすべての警告が荒野で泣いている人の声であることを知っていました。



そして、21世紀の最初の10年で、禁止が解除され、NOSQL運動が誕生しました。 ある種の奇跡、洞察力の輝く光だと思いました。 最後に、大規模で、太く、低速で、高価な、メモリを消費するリレーショナルデータベースを必要としないシステムが世界中に存在する可能性があることに気付きました。



80年代の小さな醸造所のように、BigTable、Mongo、CouchDB、その他のかわいい小さなデータベースシステムが成長し始めるのを楽しみにして見ました。 ビールが帰ってきた！ そしてそれはおいしくなります。



しかし、その後、私は何かに気づきました。 これらのキュートでシンプルでエレガントな非リレーショナルデータベースを使用するいくつかのシステムは、データベースを中心に設計されています 。 きらめく斬新なフレームワークに包まれたデータベースはまだ中心にあります！ デザイナーの頭の中では、有毒なリレーショナル広告のナンセンスが浮かび上がります。 彼らはまだ致命的な間違いを犯します。



「待って！」私は叫んだ。 -「待って！ 分かりません。 わかりません。」しかし、勢いが大きすぎました。 フレームワークの巨大な銀河が生じ、それは私たちの業界に落ち、世界を引き継いだ。 これらのフレームワークはデータベースにまたがり、アプリケーションのコアをキャプチャして保持するために戦いました。 データベースを管理および装飾するために呼び出されました。 リレーショナルデータベースをNoSQLデータベースに変えることができるとさえ主張されました。 そして、フレームワークは全世界に大声で叫びました：「私に頼ってください、そして、私はあなたを自由にします！」。



この記事のタイトルは「Not a DB」です。 おそらくこれらの暴言の後、あなたが私にそれを彼女に電話した理由がわかるでしょう。



アプリケーションの基盤はデータベースではありません。 また、使用できるフレームワークもありません。 アプリケーションの基礎は、そのユースケースです。



開発者が「Tomcat with Spring and Hibernate on Oracle」のスタイルで彼のプロジェクトを説明しているのを聞くと、私は夢中になります。 文言自体は、フレームワークとデータベースを最前線に置いています。



このシステムのアーキテクチャはどのように見えると思いますか？ あなたは思う

設計の中核に使用シナリオがありますか？ それとも、ソースコードがフレームワークモデルによりよく適合するように調整されていることに気付きますか？ ビジネスオブジェクトがテーブルの行に不審に似ていることに気づきましたか？ データスキーマとフレームワーク全体が大きすぎますか？



これは、アプリケーションの外観です。 ユースケースは、最も重要で最も目に見える建築物でなければなりません。 使用シナリオが基盤です。 いつも！ データベースとフレームワーク-詳細！ 最初から選択する必要はありません。 すべてのユースケースとビジネスロジックが定式化され、記録され、 検証されるまで、後まで延期できます。



データモデルを決定するのに最適な時期はいつですか？ データオブジェクトが何であるか、それらがどのように接続され、どのように使用されるかがわかっている場合。 いつわかりますか？ すべてのユースケースとビジネスルールが記録され、 検証されている場合 。 その時までに、すべてのクエリ、関係、およびデータ要素を決定し、データベースに最適なデータモデルを構築できるようになります。



NoSQLデータベースを使用している場合、何か変更が必要ですか？ もちろん違います！ データベースについて考える前に、データベースの種類に注意を払うことなく、使用シナリオの記録と検証を確実にすることに引き続き焦点を当てています。



設計の初期段階に参加するデータベースは、プロジェクトのアーキテクチャをゆがめます。 彼女はシステムの心臓部のために戦い、そこに侵入すると、髪にチューインガムのような足場を獲得します。 データベースをシステムの中心に入れないようにする必要があります。 データベースで忙しくするためには、誘惑に絶えず「いいえ」と言わなければなりません。



興味深い時間が先にあります。 さまざまなストレージテクノロジーの禁止が解除された時代であり、多くの新しいアプローチを自由に試すことができます。 しかし、CouchDBを使用したゲームでも、MongoとBigTableは忘れないでください。 データベースは、ただちに解決策を必要としないコンポーネントです 。