過去10年間、アプリケーションの開発に伴いデータベース設計を進化させるための数々の技術を開発・改良してきました。これはアジャイル手法において非常に重要な機能です。これらの技術は、継続的インテグレーションとデータベース開発への自動化されたリファクタリング、そしてDBAとアプリケーション開発者間の緊密な連携に基づいています。これらの技術は、本番前システムとリリース済みのシステムの両方、グリーンフィールドプロジェクトとレガシーシステムの両方で機能します。

私と同僚のバドリとの間のヘキサゴナルアーキテクチャとそのRailsアプリケーションにおける役割に関する会話のビデオをいくつか紹介します。最初のビデオでは、ヘキサゴナルアーキテクチャの意味と、それが永続化フレームワークのActive RecordパターンとData Mapperパターンの選択につながる方法について説明します。2つ目のビデオでは、Railsがアプリケーションにおいて果たすべきアーキテクチャ上の役割、つまりRailsをプラットフォームと見なすべきか、コンポーネントのスイートと見なすべきかについて、より広範に議論します。

QCon London 2012での基調講演では、データが私たちの人生において果たしている役割（そしてそれが単に大きくなっているだけではないこと）について考察しています。まず、データの世界がどのように変化しているか、つまりデータの増加、分散化、接続性の向上について見ていきます。次に、業界の対応、つまりNoSQLの台頭、サービス統合への移行、イベントソーシングの出現、クラウドの影響、可視化の役割が拡大した新しい分析について見ていきます。現在データがどのように使用されているかを簡単に見ていきます。特にレベッカは発展途上国におけるデータに重点を置いています。最後に、ソフトウェア専門家としての私たちの個人的な責任に、これらすべてがどのような意味を持つのかを検討します。

goto Aarhusでは、NoSQLに関する実践的な経験に関するトラックがありました。NoSQLデータストアの基本原理を説明する最初の講演をするように依頼されました。NoSQLの起源、NoSQLデータモデルの形式、多くのNoSQLデータベースが整合性の問題をどのように考えているか、そしてポリグロットパーシスタンスの重要性について説明します。

近年、スキーマレスデータの利点について議論されることが増えています。スキーマレスであることは、NoSQLデータベースへの関心の主な理由の1つです。しかし、データベースとインメモリデータ構造の両方において、スキーマレスには多くの微妙な点があります。これらの微妙な点は、スキーマレスの意味、およびスキーマレスアプローチを使用することの利点と欠点の両方において存在します。

プラモード・サダラージは、Thoughtworksで現在習慣的に使用しているアジャイルデータベース技術の開発を主導しました。SE Radioでは、これらの技術を使用して、それを使用するアプリケーションと共にデータベースの設計を反復的に進化させる方法についてインタビューしています。データベースを継続的インテグレーションシステムに組み込む方法、反復可能なスクリプト化されたマイグレーションを通じてデータベースの変更を行う方法、およびデータベースのリファクタリングの方法について説明します。

主にアプリケーション開発の管理に関わる人向けに書かれた、エンタープライズにおけるデータストレージの未来に関するInfoDeckです。リレーショナルデータベースがなぜ優勢だったのか、NoSQLがなぜこの仮定に挑戦しているのかを説明し、複数のデータストレージテクノロジーがその多様なニーズに応じてアプリケーションに使用されるポリグロットパーシスタンスの未来を概説しています。

過去20年間で、データベース指向のソフトウェア開発者とインメモリアプリケーションソフトウェア開発者の間のギャップが広がってきました。これにより、SQLやストアドプロシージャなどのデータベース機能の使用方法について多くの論争が生じています。この記事では、単純ながらも豊富なSQLクエリの一例に基づいて、パフォーマンスと保守性の観点から、ビジネスロジックをSQLクエリに配置するか、インメモリコードに配置するかという問題について考察します。

Nosql Distilledに取り組んでいる中で最初に頭に浮かんだトピックの1つは、NoSQLデータベースがリレーショナルモデルとは異なるデータモデルを使用しているということでした。私が調べてきたほとんどの情報源では、少なくとも4つのデータモデルグループ、キーバリュー、ドキュメント、列ファミリ、グラフが言及されています。このリストを見ると、最初の3つには大きな類似点があります。すべて、密接に関連するデータの豊富な構造である基本的なストレージ単位を持っています。キーバリューストアでは値、ドキュメントストアではドキュメント、列ファミリストアでは列ファミリです。DDDの用語では、このデータグループはDDD_Aggregateです。

私は、単一のアプリケーションによって制御およびアクセスされるデータベース（IntegrationDatabaseとは対照的に）をアプリケーションデータベースという用語で表現します。単一のアプリケーションだけがデータベースにアクセスするため、その1つのアプリケーションのニーズを簡単に満たせるようにデータベースを具体的に定義できます。これにより、通常は理解しやすく、IntegrationDatabaseよりも複雑さが少ない、より具体的なスキーマが作成されます。

データレイクとは、この10年で登場した用語であり、ビッグデータの世界におけるデータ分析パイプラインの重要なコンポーネントを表しています。その考え方は、組織内の誰でも分析するために必要なすべての生データを単一のストアに保存することです。一般的に、人々はHadoopを使用してレイク内のデータに対して作業しますが、この概念はHadoopだけにとどまりません。

私が初期に気に入った本の1つは、Tsichritzis and Lochovskyのデータモデルに関する本でした。この本では、データについて考えるためのさまざまなモデル、特に当時最も議論されていた3つのモデルであるリレーショナルデータモデル、階層型データモデル、ネットワークデータモデルについて説明しています。

データベースとアプリケーションの関係について話すとき、私はアプリケーションデータベースとIntegrationDatabaseの2つのデータベーススタイルを区別することが有用であると考えています。この2つの違いは、データベースが単一のアプリケーション境界内で制御およびカプセル化されているかどうかです。

数年前、プログラミング言語の人々がJavaによって引き起こされた言語における「核の冬」について話しているのを聞きました。その気持ちは、誰もがJavaの計算モデルに収束していたため（その時点でC#は単なる模倣と見なされていた）、プログラミング言語の創造性が消えてしまったというものでした。その気持ちは現在薄れてきていますが、おそらくより重要な解凍が始まっているかもしれません。それは、データベースについて考える際のより長く、より深い凍結です。

データンスパアザムケイトは、英語に正しく翻訳するのが難しいドイツ語です。これは、私たちがデータを取得および保存する方法に対する態度であり、本当に必要なデータのみを処理する必要があることを示しています。

階層型データモデルは、階層またはツリー構造としてデータを編成します。初期のデータベースやプログラミングデータ構造では階層型モデルがよく使用されていましたが、次第に廃れていきました。データベースの世界ではリレーショナルデータモデルが主流となり、ほとんどのインメモリプログラミングではネットワークデータモデルが主流となっています。これは、階層構造が単純な組織化ツールである一方で、データが複雑になるにつれて破綻する傾向があるためです。

インメモリデータベースは、ディスクにアクセスすることなく、主メモリだけで完全に動作するデータベースです。多くの場合、組み込みデータベースとして動作します。つまり、プロセスが開始されると作成され、そのプロセス内で埋め込まれて実行され、プロセスが終了すると破棄されます。

どの職業にも共通することですが、ソフトウェア開発にも、しばしば忘れられ、通常は無視されますが、まさに悪いタイミングで問題を引き起こす可能性のある活動があります。その一つがデータ移行です。

統合データベースは、複数のアプリケーションのデータストアとして機能し、それらのアプリケーション間でデータを統合するデータベースです（アプリケーションデータベースとは対照的です）。

エンタープライズアプリケーションの開発を始める際、最初に検討される質問の一つは「データベースとどのように通信するか」です。最近は、「リレーショナルデータベースか、NoSQLデータベースのどちらを使用すべきか」という質問をすることもありますが、もう一つ考慮すべき質問があります。「そもそもデータベースを使用する必要があるのか？」ということです。

ネットワークデータモデルは、データをレコードタイプとして構造化し、ポインタリンクを使用してレコード間を移動できるようにします。したがって、ネットワークデータモデルをクエリするには、あるレコードから開始してポインタ参照をたどります。

多くの組織では、永続的なデータは、中央データベース管理グループによって管理されるリレーショナルデータベースに格納されることが期待されています。このような中央制御にはさまざまな理由があり、通常は統合データベースの使用を中心としています。中央データグループは、不正なデータ、重要な共有リソースを遅延させる可能性のあるクエリ、および企業全体での一貫性のあるデータモデルを防ぐことに配慮しています。

これらの目標は価値のあるものかもしれませんが、その結果として、データの格納に関する相当な儀式が発生します。データベースに列を追加するのに数週間かかる変更依頼に関する苦情をよく耳にします。短サイクルの進化的な設計に慣れている現代のアプリケーション開発者にとって、そのような儀式は遅すぎるだけでなく、煩わしいものです。

そのため、アプリケーション開発グループは、DBAを回避するためにNoSQLデータベースを使用していると私に話します。「適切なデータベース」ではなく「単なるデータストア」を使用しているためです。そうすることで、DBAをループから外すことができ、しばしば伝えられることもなく、または気にしないことを喜んで受け入れています。

Nosql Distilledの作業を開始したとき、私たちは難しい問題に直面しました―私たちは一体何について書いているのでしょうか？NoSQLデータベースとは正確には何でしょうか？この概念の明確な定義はなく、商標も、標準化団体も、マニフェストさえありません。

数ヶ月前にロンドンのQConカンファレンスに参加した際、すべての講演でオブジェクト/リレーショナルマッピング（ORM）ツールに関する皮肉な発言が含まれているように見えました。講演者に送られたカンファレンスのメールをもっと注意深く読むべきだったのでしょう。間違いなく、45分ごとに少なくとも一度はORMを軽蔑するよう私たち全員に指示する何かがあったはずです。しかし、お分かりのように、私はこのORMへの反感に少し反論したいと思っています。なぜなら、その多くは根拠がないと考えるからです。

2006年、私の同僚であるニール・フォードは、ポリグロットプログラミングという用語を作り出し、異なる言語が異なる問題に対処するのに適しているという事実を利用するために、アプリケーションを複数の言語で記述するべきであるという考え方を表現しました。複雑なアプリケーションはさまざまな種類の問題を組み合わせているため、適切な言語を選択することが、すべての側面を単一の言語に合わせようとするよりも生産性が高くなる可能性があります。

ここ数年、特に関数型言語において新しい言語への関心が爆発的に増加しており、私はClojure、Scala、Erlangなどを学ぶことに時間を費やしたいと思うことがよくあります。しかし、私の時間は限られており、より重要な変化であるDatabaseThawに高い優先順位を付けています。クライアントや他の関係者から最初の兆候が見え始めており、その見通しは魅力的です。新しい戦略的なエンタープライズアプリケーションの開発を開始する場合、永続化がリレーショナルであると想定すべきではないと断言できます。リレーショナルオプションが適切な場合もあるかもしれませんが、他の選択肢も真剣に検討する必要があります。

情報量の多いプログラムをモジュール化するための最も一般的な方法の1つは、プレゼンテーション（UI）、ドメインロジック（ビジネスロジック）、データアクセスという3つの広範なレイヤーに分けることです。そのため、Webアプリケーションは、HTTPリクエストの処理とHTMLのレンダリングに関する知識を持つWebレイヤー、検証と計算を含むビジネスロジックレイヤー、データベースまたはリモートサービスで永続的なデータを管理する方法を処理するデータアクセスレイヤーに分割されることがよくあります。

リレーショナルデータモデルは、ほとんどの人にとって、リレーショナルデータベースとSQL言語を通じて最もよく知られています。口語的には、データベースを一連のテーブルと見なし、各行にデータが含まれています。これらのテーブルをさまざまな方法で操作してクエリを実行でき、各クエリは別のテーブルになります。ネットワークデータモデルとは異なり、テーブル間に明示的なポインタはありません。リンクは共通の値に基づく結合テーブルによって作成されます（ただし、サロゲートキーを使用すると、実際にはポインタが存在します）。

ほとんどのエンタープライズアプリケーションは、データベースを使用して永続的なデータを格納します。このデータベースは、アプリケーションの状態の運用上の更新と、意思決定支援と分析に使用されるさまざまなレポートの両方をサポートします。ただし、運用上のニーズとレポート作成のニーズは、多くの場合、スキーマに対する要件とデータアクセスパターンが異なるため、非常に異なります。このような場合、レポート作成のニーズをレポーティングデータベースに分割することが賢明な場合があります。これは、重要な運用データのコピーを取得しますが、異なるスキーマで表現します。

多くのプログラムは、作成と維持にコストのかかるリソースを使用する必要があります。その例としては、データベース接続やスレッドがあります。リソースプールは、これらのリソースを管理するための優れた方法を提供します。

数年前、eBayで作業をしていた2人の友人と話をしました。大規模サイトで使用されている手法について話を聞くのは常に興味深いことですが、おそらく最も興味深い情報の1つは、eBayではほとんどの場合、データベーストランザクションをほとんど使用していないということです。

ソフトウェアシステムの一般的な機能は、ユーザーがデータ構造に独自のフィールドを定義できるようにすることです。アドレス帳を考えてみましょう。追加したいものがたくさんあります。新しいソーシャルネットワークが毎日登場しているため、ユーザーは連絡先に新しいBunglr IDのフィールドを追加したいと思うかもしれません。

goto（旧JAOO）は、長年私の好きなカンファレンスの1つです。彼らは長年にわたり、高いレベルのコンテンツと効率的でフレンドリーな組織運営を組み合わせることで素晴らしい仕事を成し遂げてきました。そのため、カンファレンスへの過剰な参加により、一般的にカンファレンス恐怖症になっている私ですが、オーフスのやや複雑な旅行に向かう際に、楽しい期待感を感じています。