新しいソフトウェアプロジェクトを開発する際、最も重要なことは適切なツールを選択することであり、最も重要なツールの1つがデータベースエンジンである。

以下では、SQLとNoSQLのデータベースエンジンの長所と短所について説明し、プロジェクトに最適なものを選択するための情報を提供します。PCとMacの議論に似ていますが、この記事ではできるだけ客観的で公平な意見を述べることを目指します。

エスエル

SQLは1970年代に開発され、1979年に言語としてリリースされ、現在でもリレーショナルデータベースと通信するための主要な言語である。

SQLは業界のデファクトスタンダードなので、SQLに慣れている開発者であれば、異なるデータベースエンジンの利用を容易に切り替えることができます。

リレーショナルデータベースは、テーブルとカラムからなる定義済みのスキーマを必要とし、各レコードはテーブルの行となる。スキーマはいつでも簡単に変更できますが、必要なデータをすべて正しくデータベースに入れるためには、ある程度の事前準備が必要です。列は、文字列、整数、浮動小数点、大きなテキスト要素、バイナリブロブなど、さまざまなデータ型のいずれかにすることができる。

リレーショナルデータベース

リレーショナルデータベースの構造設計により、テーブル間の子-親関係を簡単に作成することができます。

例えば、"users" テーブルの "id" カラムは "notes" テーブルの "userid" カラムとリンクしている" を "ノート" 表に表示します。カスケードをサポートしているため、親行が削除または更新されると、すべての子行も影響を受けます。これにより、常に構造の整合性を確保できるだけでなく、複数のテーブルに対してクエリーを実行する際に最適なパフォーマンスと速度を実現することができます。

しかし、大規模なデータベーススキーマを適切に設計・管理することは、それ自体が大変な作業であり、多くの開発者が放棄することを選択してきました。大規模なデータベースの場合、スキーマの変更にも非常に時間がかかるため、適切な準備が必要です。

一方、構造化された設計は、そのソフトウェアを使用する他の開発者にとっても、データベースがどのように構成されているかが明確に分かるため、より簡単なルートを提供することができます。

nosql

MongoDBを筆頭に、NoSQLデータベースはここ数年で大きな人気を獲得しています。これは、スキーマレス構造（あらかじめ定義されたデータベーススキーマがない）とJSONオブジェクトの使用（開発者に馴染みのあるレコードを提供する）によるところが大きいです。

NoSQLデータベースは、テーブルと行の代わりに、コレクションとドキュメントを使用します。データベーススキーマを事前に定義する必要はなく、すべてが動的に自動作成されます。例えば、存在しないコレクションに **documents** を入れようとすると、エラーを投げる代わりに、コレクションが動的に自動作成されます。

ドキュメントはJSONオブジェクトであり、JSONはすでに開発者が日常的に使用しているため、馴染みがある。文書には定義された構造がないため、あらゆるデータが文書内に格納される可能性があり、文書間で異なる可能性もある。

これにより、データベーススキーマの作成・管理の手間が省けるだけでなく、データベースの制約によるエラーを発生させることなく、任意のデータを一つのドキュメントに追加できるなど、非常に柔軟な対応が可能となります。

構造的健全性の低下

NoSQL は柔軟性と親しみやすさに優れていますが、欠点として制約のサポートがないため、SQL よりも構造の整合性が低くなります。コレクション間の関係やカスケードを確実にサポートしないため、孤立した子レコードを削除しても親レコードがデータベースに残ってしまい、複数のデータセットにわたる関連レコード処理の最適化が低下するなどの問題が発生する可能性があります。

また、このような非構造的な設計は、ソフトウェアに未検出のエラーを追加することにつながります。例えば、開発者がタイプミスをして「amount」ではなく「amont」と入力しても、NoSQLデータベースはエラーや警告を出さずにそれを受け入れてくれる。

sql vs nosql: どのデータベースが最適か？

ソフトウェア開発に関してはいつもそうですが、答えは「状況次第」です。

例えば、保険や教育財政、家系図の記録など、より非構造化データを保存する必要がある場合、NoSQLはスキーマフリー構造により、文書内に**任意のデータを追加することができるので、良い選択でしょう。

しかし、複数のテーブルにまたがる大きなレコードが必要で、構造の整合性とクエリの性能を優先する場合は、SQLの方が適しているかもしれません。