データベースとは何ですか？

はじめに

データベースは、多くの最新のアプリケーションやツールにとって不可欠なコンポーネントです。ユーザーは、Webサイトにアクセスしたり、電話でアプリケーションを使用したり、食料品店で商品を購入したりするときに、毎日数十または数百のデータベースを操作する可能性があります。開発者として、データベースは、アプリケーションの存続期間を超えてデータを永続化するために使用されるコアコンポーネントです。しかし、データベースとは正確には何であり、なぜそれらはそれほど一般的ですか？

この記事では、以下について説明します。

• データベースとは
• さまざまな種類のデータを追跡するために、人やアプリケーションがそれらをどのように使用するか
• データベースが提供する機能
• どのような種類の保証を行うか
• 他のデータストレージ方法との比較

最後に、複雑な機能を有効にするために、アプリケーションがデータの保存と取得をデータベースにどのように依存しているかについて説明します。

データベースとは何ですか？

データベース は、将来の処理、取得、または評価のためにデータを整理および保存するために使用される論理構造です。コンピュータのコンテキストでは、これらの構造はほとんどの場合、データベース管理システムと呼ばれるアプリケーションによって管理されます。 またはDBMS 。 DBMSは、コンピューターのディスク上の専用ファイルを管理し、ユーザーとアプリケーションに論理インターフェイスを提供します。

データベース管理システムは通常、特定のパターンに従ってデータを整理するように設計されています。これらのパターンは、データベースタイプと呼ばれます またはデータベースモデルは、個々のデータをどのように保存および管理するかを決定する論理的および構造的な基盤です。多くの異なるデータベースタイプがあり、それぞれに独自の利点と制限があります。 リレーショナルモデル 、データを相互参照されたテーブル、行、および列に編成することは、多くの場合、デフォルトのパラダイムと見なされます。

DBMSは、コマンドラインクライアント、API、プログラミングライブラリ、管理インターフェイスなど、さまざまな手段を介して、管理するデータベースにアクセスできるようにすることができます。これらのチャネルを通じて、データをシステムに取り込み、必要に応じて整理し、要求に応じて返すことができます。

データの永続性と一時的なストレージ

データベースは、データをディスクまたはメモリ内に保存します。

ディスク上のストレージは、一般的に永続的と言われています 、つまり、データベースアプリケーションまたはコンピュータ自体が再起動した場合でも、データは後で確実に保存されます。

対照的に、メモリ内ストレージはエフェメラルと言われています または揮発性 。エフェメラルストレージは、アプリケーションまたはシステムのシャットダウンに耐えられません。インメモリデータベースの利点は、通常、非常に高速であるということです。

実際には、多くの環境では、これらのタイプのシステムの両方を組み合わせて使用​​して、各タイプの利点を活用します。エフェメラルレイヤーへの新しい書き込みを受け入れるシステムの場合、これはエフェメラルデータをディスクに定期的に保存することで実現できます。他のシステムは、永続データの読み取り専用のメモリ内コピーを使用して、読み取りアクセスを高速化します。これらのシステムは、いつでもバッキングストレージからデータをリロードして、データを更新できます。

データベースと対話してデータを管理する

データベースシステムは、データをディスクまたはメモリ内に保存する方法を処理しますが、ユーザーまたはアプリケーションのインターフェイスも提供します。データベースのインターフェイスは、外部の関係者が実行できる操作を表すことができ、システムがサポートするすべてのデータ型を表すことができる必要があります。

ウィキペディアによると、データベースは通常、次の4種類の対話を許可します。

• データ定義 ：データの構造の定義を作成、変更、および削除します。これらの操作は、データベースがデータを受け入れて保存する方法に影響を与えるプロパティを変更します。これは、一部の種類のデータベースでは他の種類よりも重要です。
• 更新 ：データベース内のデータを挿入、変更、および削除します。これらの操作により、管理されている実際のデータが変更されます。
• 取得 ：保存されたデータへのアクセスを提供します。データはそのまま取得することも、多くの場合、フィルタリングまたは変換して、より有用な形式に変換することもできます。多くのデータベースシステムは、これを実現するために豊富なクエリ言語を理解しています。
• 管理 ：ユーザー管理、セキュリティ、パフォーマンスモニタリングなど、必要であるがデータ自体に直接関係しないその他のタスク。

これらについて、以下でもう少し詳しく見ていきましょう。

データ定義は、システム内のデータの形状と構造を制御します

データベース内でデータがとる構造を作成および制御することは、データベース管理の重要な部分です。これは、データをシステムに取り込む前に、データの形状または構造を制御するのに役立ちます。また、データが特定のパラメータに準拠していることを確認するための制約を設定することもできます。

リレーショナルデータベースのように非常に規則的なデータを操作するデータベースでは、これらの定義はデータベースのスキーマと呼ばれることがよくあります。 。データベーススキーマは、特定のデータベースで受け入れられるようにデータをフォーマットする方法の厳密な概要です。これには、個々のレコードに存在する必要のある特定のフィールドと、データ型、フィールド長、最小値または最大値などの値の要件が含まれます。データベーススキーマは、データベース所有者が影響を与えなければならない最も重要なツールの1つです。システムに保存されるデータを制御します。

規則性よりも柔軟性を重視するデータベース管理システムは、多くの場合、スキーマレスデータベースと呼ばれます。 。これは、これらのデータベース内に格納されているデータに構造がないことを意味しているように見えますが、通常はそうではありません。代わりに、データベースの構造は、データ自体と、データに関するアプリケーションの知識とデータとの関係によって決定されます。データベースは通常、構造に準拠していますが、データベース管理システムは制約の適用にあまり関与していません。これは、状況に応じて長所と短所がある設計上の選択です。

システムからデータを取り込み、変更し、削除するためのデータ更新

データの更新には、次のような操作が含まれます。

• システムに新しいデータを入力します
• 既存のエントリを変更します
• データベースからエントリを削除します

これらの機能はどのデータベースにも不可欠であり、多くの場合、データベースシステムが処理するアクションの大部分を構成します。これらのタイプのアクティビティ（システム内のデータに変更を加える操作）は、まとめて書き込みと呼ばれます。 操作。

書き込みアクションは、時間の経過とともに変化するデータソースにとって重要です。破壊的なアクションであるデータの削除でさえ、システム内のデータを変更するため、書き込み操作と見なされます。

書き込み操作はデータを変更する可能性があるため、これらのアクションは潜在的に危険です。ほとんどのデータベース管理者は、書き込み操作を特定のアプリケーションプロセスに制限して、偶発的または悪意のあるデータの操作の可能性を最小限に抑えるようにシステムを構成します。たとえば、既存のデータを使用してWebサイトのパフォーマンスや訪問者の行動に関する質問に答えるデータ分析では、読み取り権限のみが必要です。一方、ユーザーの注文を記録するアプリケーションの部分は、データベースに新しいデータを書き込める必要があります。

データを取得して情報を抽出したり、特定の質問に回答したりする

必要なときにデータを取得する方法がない限り、データの保存はあまり役に立ちません。データを返すことは、データベースに現在保存されている情報には影響しないため、これらのアクションは読み取りと呼ばれます。 オペレーション。読み取り操作は、データベース内にすでに保存されているデータを収集するための主要な方法です。

データベース管理システムには、ほとんどの場合、主キーと呼ばれることが多い一意の識別子を使用してデータにアクセスする簡単な方法があります。 。これにより、キーを提供することで、任意の1つのエントリにアクセスできます。

多くのシステムには、特定の基準に一致するデータセットを返すか、エントリに関する部分的な情報を返すようにデータベースをクエリする高度な方法もあります。このタイプのクエリの柔軟性は、データベース管理システムが基本的なデータストレージ機能に加えてデータプロセッサとして機能するのに役立ちます。特定のクエリを開発することにより、ユーザーはデータベースシステムに必要な情報のみを返すように促すことができます。この機能は、多くの場合、書き込み操作と組み合わせて使用​​され、プロパティによって特定のレコードを見つけて変更します。

すべてをスムーズに実行し続けるためのデータベースシステムの管理

データベースが頻繁にサポートするアクションの最後のカテゴリは、管理機能です。これは、データ自体に直接影響を与えることなくデータベース環境をサポートするのに役立つ、幅広く一般的なクラスのアクションです。このグループに当てはまる可能性のあるアイテムは次のとおりです。

• ユーザー、権限、認証、承認の管理
• バックアップの設定と保​​守
• ストレージ用のバッキングメディアの構成
• レプリケーションおよびその他のスケーリングに関する考慮事項の管理
• オンラインおよびオフラインのリカバリオプションを提供する

この一連のアクションは、最新のアプリケーションに共通する基本的な管理上の懸念事項と一致しています。

管理操作はコアデータ管理機能の中心ではないかもしれませんが、これらの機能は多くの場合、同様のデータベース管理システムを際立たせます。データを簡単にバックアップおよび復元したり、既存のシステムに接続するユーザー管理を実装したり、需要に合わせてデータベースを拡張したりできることは、すべて本番環境での運用に不可欠な機能です。これらの領域に注意を払わないデータベースは、実際の環境で採用するのに苦労することがよくあります。

データベースにはどのような責任がありますか？

上記の説明を踏まえて、データベースが持つ主な責任をどのように一般化できますか？答えは、使用されているデータベースのタイプとアプリケーションの要件に大きく依存します。それでも、すべてのデータベースが提供しようとしている共通の一連の責任があります。

忠実な記録と再構成によるデータの整合性の保護

データの整合性は、その目的や設計に関係なく、データベースシステムの基本的な要件です。データベースにロードされたデータは、予期しない変更、操作、または消去なしで確実に取得できる必要があります。これには、データをロードおよび取得する信頼性の高い方法と、物理メディアに保存するために必要に応じてデータをシリアル化および逆シリアル化する方法が必要です。

データベースは、多くの場合、チェックサムなどの書き込みまたは取得時にデータを検証したり、ログ先行書き込みなどの手法を使用して予期しないシャットダウンによって引き起こされた問題から保護したりする機能に依存しています。システムの各部分は各データ項目の現在の望ましい状態を反映する必要があるため、データストアが分散しているほど、データの整合性はより困難になります。これは多くの場合、システムでデータが変更されるたびに、より堅牢な要件と複数のメンバーからの応答によって実現されます。

展開環境の要件を満たすパフォーマンスを提供する

データベースは、有用であるために適切に機能する必要があります。必要なパフォーマンス特性は、アプリケーションの特定の要求に大きく依存します。すべての環境には、読み取り要求と書き込み要求の独自のバランスがあり、これらのカテゴリの両方で許容できるパフォーマンスが何を意味するかを決定する必要があります。

データベースは一般に、特定のタイプの操作を他のタイプよりも実行するのに優れています。運用パフォーマンスの特性は、多くの場合、使用されるデータベースのタイプ、データスキーマまたは構造、および運用自体を反映しています。場合によっては、インデックス作成などの機能 は、一般的にアクセスされるデータの代替のパフォーマンス最適化ストアを作成し、これらのアイテムのより高速な取得を提供できます。また、データベースが要求されているアクセスパターンに適していない場合もあります。これは、必要なデータベースのタイプを決定する際に考慮すべきことです。

安全な同時アクセスを可能にするプロセスの設定

これは厳密な要件ではありませんが、実際には、データベースは同時アクセスを許可する必要があります。これは、複数の関係者が同時にデータベースを操作できる必要があることを意味します。レコードは、任意の数のユーザーが同時に読み取り可能であり、現在別のユーザーによってロックされていないときに書き込み可能である必要があります。

同時アクセスとは、通常、データベースがユーザーアカウント、アクセス許可システム、認証および承認メカニズムなどの他の基本機能を実装する必要があることを意味します。また、複数のユーザーが同じデータを同時に操作しようとするのを防ぐための戦略を開発する必要があります。これらの懸念に対処するために、レコードロックとトランザクションが実装されることがよくあります。

データを個別にまたはまとめて取得する

データベースの基本的な責任の1つは、要求に応じてデータを取得する機能です。リクエストは、単一のレコードに関連付けられた個々のデータに対するものである場合もあれば、多くの異なるレコードで見つかったデータの取得を伴う場合もあります。これらのケースは両方とも、ほとんどのシステムで可能である必要があります。

ほとんどのデータベースでは、取得時にデータベース自体によってある程度のデータ処理が提供されます。これらには、次のタイプの操作が含まれる場合があります。

• 基準による検索
• フィルタリングと制約の順守
• 特定のフィールドの抽出
• 平均化、並べ替えなど

これらのオプションは、必要なデータと最も役立つ形式を明確にするのに役立ちます。

データベースの代替案

先に進む前に、データベースを使用しない場合の選択肢を簡単に確認する必要があります。

データを格納するほとんどのメソッドは、ある種のデータベースとして分類できます。いくつかの例外には、次のものがあります。

ローカルメモリまたは一時ファイルシステム

アプリケーションが、役に立たないデータや、アプリケーションの存続期間にのみ関連するデータを生成する場合があります。このような場合、アプリケーションが終了するとデータは不要になるため、そのデータをメモリに保持するか、一時ファイルシステムにオフロードすることをお勧めします。データが役に立たない場合は、出力を完全に無効にするか、/dev/nullに記録することをお勧めします。 。

アプリケーションデータをローカルファイルシステムに直接シリアル化する

データベースが不要になる可能性があるもう1つの例は、代わりに少量のデータを直接シリアル化および逆シリアル化できる場合です。これは、同時実行性がほとんどない予測可能な使用パターンを持つ少量のデータに対してのみ実用的です。これは適切に拡張できませんが、ローカルログ情報の出力などの特定の場合に役立ちます。

ファイルのようなオブジェクトをディスクまたはオブジェクトストレージに直接保存する

アプリケーションからのデータは、データベースに保存する代わりに、ディスクまたは代替ストアに直接書き込むことができる場合があります。たとえば、データが画像や音声ファイルなどのファイル指向の形式にすでに整理されていて、追加のメタデータを必要としない場合は、ディスクまたは専用のオブジェクトストアに直接保存するのが最も簡単な場合があります。

データベースは何に使用されますか？

完全に静的ではないほとんどすべてのアプリケーションとWebサイトは、環境内のどこかにあるデータベースに依存しています。データベースの主な目的は、多くの場合、使用されるデータベースのタイプ、保存されるデータ、および使用されるアクセスパターンを決定します。多くの場合、さまざまな要件を持つさまざまなタイプのデータを処理するために、複数のデータベースシステムが展開されます。一部のデータベースは、さまざまなデータセットの性質に応じて複数の役割を果たすのに十分な柔軟性を備えています。

典型的なWebアプリケーションがデータベースと持つ可能性のあるタッチポイントについて説明する例を見てみましょう。アプリケーションに基本的なストアフロントが含まれていて、追跡するアイテムを在庫で販売しているように見せかけます。

サイトデータの保存と処理

データベースの主な用途の1つは、サイトに関連するデータの保存と処理です。これらの項目は、サイト上の情報の編成方法に影響を与え、多くの場合、サイトの「コンテンツ」の大部分を構成します。

上記のサンプルアプリケーションでは、データベースは、製品情報、在庫の詳細、ユーザープロファイル情報など、サイトのほとんどのコンテンツを入力します。これは、製品リスト、製品詳細ページ、またはユーザープロファイルを表示する必要があるたびに、データベースまたはいくつかの中間キャッシュが参照されることを意味します。

現在および過去の注文を表示したり、送料を計算したり、割引コードを確認したり、頻繁な顧客報酬を計算したりして割引を適用する場合にも、データベースが必要になります。このサンプルサイトでは、データベースシステムを使用して、製品情報、在庫、およびユーザー情報を組み合わせて注文を正しく作成します。注文に記録された複合情報は、注文処理の追跡、返品の許可、注文のキャンセルまたは変更、またはより良い顧客サポートを可能にするために、データベースに再度保存されます。

より良い意思決定に役立つ情報の分析

最後のカテゴリのアクションは、Webサイトの基本的な機能に関連していました。これらはアプリケーション層のデータ要件を処理するために非常に重要ですが、全体像を表すものではありません。

Webアプリケーションがユーザーの登録と注文の処理を開始したら、さまざまな製品の販売状況、最も収益性の高いユーザー、および販売に影響を与える要因に関する詳細な質問に答えられるようにしたいと思うでしょう。これらは、組織の傾向とパフォーマンスに関する最新のインテリジェンスを収集するためにいつでも実行できる分析的な質問です。

これらのタイプの操作は、多くの場合、ビジネスインテリジェンスと呼ばれます。 または分析 。一緒に、それらは組織が過去に何が起こったかを理解し、情報に基づいた変更を加えるのを助けます。データベースシステムは、これらのプロセス中に使用されるデータのほとんどを保存し、それに関する質問に答えるために適切なツールまたはクエリ機能を提供する必要があります。

このサンプルアプリケーションでは、データベースにクエリを実行して、製品の傾向、ユーザー登録番号（最も多く出荷することを示す）、または最も忠実なユーザーについての質問に答えることができます。これらの比較的基本的なクエリを使用して、より複雑な質問を作成し、製品のパフォーマンスに影響を与える要因をよりよく理解して制御できます。

ソフトウェア構成の管理

一部のタイプのデータベースは、ネットワーク上の他のソフトウェアの構成値のリポジトリとして使用されます。これらは、ネットワーク上の構成値の信頼できる唯一の情報源として機能します。新しいサービスが開始されると、構成データベースのネットワークアドレスにある特定のキーの値をチェックするように構成されます。これにより、サービスをブートストラップするために必要なすべての情報を1か所に保存できます。

ブートストラップ後、アプリケーションは、構成に関連するキーの変更を監視するように構成できます。変更が検出された場合、アプリケーションは新しい構成を使用するように自身を再構成できます。このプロセスは、新しいサービスが登場したときに古いサービスをスピンダウンし、可用性を維持するためにアクティブな構成を時間の経過とともに変更することにより、時間の経過とともに新しい値を展開する管理プロセスによって調整される場合があります。

私たちのアプリケーションは、このタイプのデータベースを使用して、アプリケーション環境全体の永続的な構成データを格納できます。アプリケーションサーバー、Webサーバー、ロードバランサー、メッセージングキューなどは、構成データベースを参照して本番環境の設定を取得するように構成できます。その後、アプリケーションの開発者は、中央の場所で構成値を微調整することにより、環境の動作を変更できます。

ログ、イベント、およびその他の出力の収集

リクエストをアクティブに処理しているアプリケーションを実行すると、大量の出力が生成される可能性があります。これには、ログファイル、イベント、およびその他の出力が含まれます。これらはディスクまたはその他の管理されていない場所に書き込むことができますが、これにより有用性が制限されます。このタイプのデータをデータベースに収集すると、予期しないことが発生した場合や、過去のパフォーマンスについて詳しく知る必要がある場合に、作業、パターンの特定、イベントの分析が容易になります。

サンプルアプリケーションでは、分析を容易にするために、各システムから1つのデータベースにログを収集する場合があります。これは、問題の原因を分析したり、環境全体の状態を理解したりする場合に、イベント間の相関関係を見つけるのに役立ちます。

これとは別に、インフラストラクチャとコードによって生成されたメトリックを時系列データベースに収集する場合があります。 、時間の経過とともに値を追跡するために特別に設計されたデータベース。このデータベースを使用して、リアルタイムの監視および視覚化ツールを強化し、アプリケーションの開発チームと運用チームにパフォーマンスやエラー率などに関する情報を提供できます。

さまざまな役割はデータベースでどのように機能しますか？

データベースは、組織内のさまざまな役割の作業の基本です。小規模なチームでは、1人または数人の個人がさまざまな役割の職務を遂行する責任を負う場合があります。大企業では、これらの責任は、専任の個人またはチームによって実行される個別の役割に分割されることがよくあります。

データアーキテクト

データアーキテクトは、データベースシステムの全体的なマクロ構造、アプリケーションと開発チームに公開するインターフェイス、および組織のデータニーズを満たすために必要な基盤となるテクノロジーとインフラストラクチャに責任を負います。

この役割の人々は通常、さまざまなアプリケーションに使用される適切なデータベースモデルと実装を決定します。彼らは、オプションを調査し、テクノロジーを決定し、それを既存のシステムと統合し、組織の包括的なデータ戦略を開発することによって、データベースの決定を実装する責任があります。彼らはデータシステムを総合的に扱い、さまざまなプロジェクトのデータモデルを決定して実装する役割を担っています。

DBA（データベース管理者）

データベース管理者（DBA）は、データシステムの円滑な実行を維持する責任がある個人です。彼らは、新しいデータシステムの計画、ソフトウェアのインストールと構成、他の関係者のためのデータベースシステムのセットアップ、およびパフォーマンスの管理を担当します。また、データベースの保護、データベースの問題の監視、および使用パターンを最適化するためのシステムの調整も担当することがよくあります。

データベース管理者は、個々のデータベースシステムと、それらを基盤となるオペレーティングシステムおよびハードウェアとうまく統合してパフォーマンスを最大化する方法の両方の専門家です。これらは、データベースを使用するチームと幅広く連携して、容量とパフォーマンスの管理を支援し、チームがデータベースシステムの問題をトラブルシューティングするのを支援します。

アプリケーション開発者

アプリケーション開発者は、さまざまな方法でデータベースを操作します。彼らはデータベースと相互作用するアプリケーションの多くを開発します。これは非常に重要です。なぜなら、これらはほとんどの場合、個々のユーザーまたは顧客がデータベースシステムによって管理されるデータと対話する方法を制御する唯一のアプリケーションだからです。パフォーマンス、正確性、信頼性は、アプリケーション開発者にとって非常に重要です。

開発者は、アプリケーションに関連付けられたデータ構造を管理して、データをディスクに永続化します。コンポーネントが調和して動作できるように、プログラミングデータをデータベースシステムにマッピングできるメカニズムを作成または使用する必要があります。アプリケーションが変更されると、データベースシステム内のデータとデータ構造の同期を維持する必要があります。開発者がデータベースをどのように操作するかについては、この記事の後半で詳しく説明します。

SRE（サイト信頼性エンジニア）および運用の専門家

SRE（サイト信頼性エンジニア）と運用の専門家は、インフラストラクチャとアプリケーション構成の観点からデータベースシステムと対話します。彼らは、追加の容量のプロビジョニング、データベースシステムの立ち上げ、データベース構成が組織のガイドラインと一致することの確認、稼働時間の監視、およびバックアップの管理を担当する場合があります。

多くの点で、これらの個人はDBAと重複する責任を負っていますが、データベースだけに焦点を当てているわけではありません。運用スタッフは、データベースシステムなど、組織の他の部分が依存するアプリケーションが確実に機能し、ダウンタイムが最小限に抑えられていることを確認します。

ビジネスインテリジェンスおよびデータアナリスト

ビジネスインテリジェンス部門とデータアナリストは、主に、データベースシステム内ですでに収集され、利用可能なデータに関心を持っています。彼らは、データ内の傾向とパターンに基づいて洞察を深め、将来のパフォーマンスを予測し、潜在的な変更について組織に助言し、マーケティングや営業などの他の部門のデータに関する質問に答えることができるように取り組んでいます。

データアナリストは通常​​、データシステムへの読み取り専用アクセスのみを使用して作業できます。それらが実行するクエリは、多くの場合、プライマリアプリケーションで使用されるものとは劇的に異なるパフォーマンス特性を持っています。このため、多くの場合、データベースレプリカまたはコピーを操作して、プライマリデータベースシステムのリソース使用量に影響を与える可能性のある、実行時間とパフォーマンスを重視する集計クエリを実行できます。

開発者としてデータベースを操作するにはどうすればよいですか？

では、実際にアプリケーション開発者としてデータベースをどのように操作するのでしょうか。基本的なレベルでは、アプリケーションが状態を管理および永続化する必要がある場合、データベースの操作はコードの重要な部分になります。

アプリケーションとデータベース間のデータの変換

データベースと通信するには、既存のインターフェースを作成または使用する必要があります。通常のネットワーク機能を使用してデータベースに直接接続したり、単純なライブラリを活用したり、高レベルのプログラミングライブラリ（クエリビルダーやORMなど）を活用したりできます。

ORM 、またはオブジェクトリレーショナルマッパーは、リレーショナルデータベースで見つかったテーブルをオブジェクト指向プログラム言語内で使用されるクラスに、またはその逆に変換するマッピングレイヤーです。この翻訳はしばしば役に立ちますが、決して完璧ではありません。 オブジェクトと相対インピーダンスの不一致 は、リレーショナルデータベースとオブジェクト指向プログラムがデータを構造化する方法の違いによって引き起こされる摩擦を説明するために使用される用語です。

リレーショナルデータベースとオブジェクト指向プログラミングは2つの特定の設計上の選択を説明していますが、アプリケーションとデータベースレイヤーの間の変換の問題は、データベースの種類やプログラミングパラダイムに関係なく存在する一般化された問題です。 データベース抽象化レイヤー は、これら2つのコンテキスト間での翻訳を担当するソフトウェアのより一般的な用語です。

データベースとの構造変更の同期を維持する

アプリケーションを開発するときに気付く重要な事実の1つは、データベースはコードベースの外部に存在するため、データ構造の変更に対処するために特別な注意が必要であるということです。この問題は、一部のデータベース設計で他の設計よりも一般的です。

アプリケーションのデータ構造をデータベースと同期するための最も一般的なアプローチは、データベース移行と呼ばれるプロセスです。 またはスキーマの移行 （どちらも口語的には単に移行として知られています）。移行には、アプリケーションのデータモデルの進化に伴う変更を反映するように、データベースの構造を更新することが含まれます。これらは通常、データベースを新しい形式に変換するために必要なステートメントを含む、進化ごとに1つずつ、一連​​のファイルの形式を取ります。

データへのアクセスを保護し、入力をサニタイズします

開発者としてデータベースを操作する際の重要な責任の1つは、アプリケーションがデータへの不正アクセスを許可しないようにすることです。データセキュリティは、多くの利害関係者にとって、広範囲にわたる多層的な問題です。最終的には、セキュリティに関する考慮事項のいくつかは、世話をする義務になります。

アプリケーションは、日常的なタスクを実行するためにデータベースへの特権アクセスを必要とします。 For safety, the database's authorization framework can help restrict the type of operations your application can perform. However, you need to ensure that your application restricts those operations appropriately. For example, if your application manages user profile data, you have to prevent a user from manipulating that access to view or edit other users' information.

One specific challenge is sanitizing user input. Sanitizing input means taking special precautions when operating on any data provided by a user. There is a long history of malicious actors using normal user input mechanisms to trick applications into revealing sensitive data. Crafting your applications to protect against these scenarios is an important skill.

Conclusion

Databases are an indispensable component in modern application development. Storing and controlling the stateful information related to your application and its environment is an important responsibility that requires reliability, performance, and flexibility.

Fortunately, there are many different database options designed to fulfil the requirements of different types of applications. In our next article, we'll take an in-depth look at the different types of databases available and how they can be used to match different types of application requirements.