ユーザーのデータをRDBMSではなくLDAPに保存する理由
LDAPを使用することは、ユーザーに関するデータを保存するための良い方法であるとよく言われます。これは、ユーザーの「ディレクトリ」が階層的であり、めったに変更されないためです。しかし、私の意見では、RDBMSの使用を排除するものではありません。 LDAPを使用する理由は何でしょうか？複数値フィールドの保存やLDAPへのカスタムフィールドの追加は簡単かもしれませんが、データベースでも実行できます（レコードが多い場合を除く）
すでに述べたように、相互運用性は、一部のタイプのサーバーソフトウェアでLDAPに非常に有利ですが、LDAPと統合するソフトウェアの多くは特定のスキーマを必要とするため、LDAPサービスをインストールして構成するだけの単純なものではありません。実行する-対話するアプリごとにスキーマに新しい要素を追加する必要がある場合があり、アプリケーションごとに認証に関して異なる制限がある場合があります（たとえば、プレーンテキストのパスワードフィールド、MD5などのパスワードフィールドまたはSHAハッシュなど）。
優れたLDAPサービスには、リレーショナルデータベースで単純なスキーマを作成するよりも、かなりの構成知識が必要です。 SQL DBは依然としてかなり相互運用可能なオプションであり、LDAPサポートはかつてほど支配的ではありません。 LDAPは数年前に唯一のオプションでしたが、多くのアプリケーション（Apacheなど）およびオペレーティングシステム（LinuxのPAMなど）は、インターフェイスを抽象化するドライバーによってすべて処理されるのと同じくらい簡単に、MySQLなどのSQLDBに対して認証できます。
LDAPが本当に優れているのは、スケーラビリティです。認証用のユーザーアカウントを保持する場所が特に必要で、複数のレプリケートされたサーバーに拡張したい場合、および1秒間に数千の認証要求を処理する傾向がある場合、LDAPは優れたオプションです。
最新のRDBMSが拡張できないわけではありません。それは、LDAPがさまざまな層を介してレプリケーションをカスケードする方法のために、（通常は）これがさらに優れているということだけです。特に、書き込み操作が比較的少なく、ほとんどが読み取り専用である一般的な認証データベースのセットアップがあると仮定すると、信頼できる唯一の情報源からのすべての書き込みで一方向のレプリケーションのみが必要になります。
ただし、実際には、LDAPサーバーは、特定の必要性がある場合に検討する必要があります。たとえば、特定のアプリケーション LDAPとのみ統合される相互運用を可能にしたい場合、または高度にスケーラブルな認証システムを構築している場合（たとえば、ISPまたは超スケーラブルなWebアプリケーションの場合-複数のサーバーを専用にする予定の場合just認証、およびそれらが全国または世界中に広がる可能性のある場所）。
RDBMSにLDAPフロントエンドを配置することについて誰かがすでに述べた点は非常に良いものです。オラクル（もちろん、RDBMSに既得権を持っている）を含むいくつかの企業は、特にそれを行う製品を持っています。 LDAPサービスを管理するオーバーヘッドが必要ない場合、またはDB内のすべてのユーザーを管理するだけの場合は、ビュー/結合を作成できますが、可能性があると考えてくださいLDAPサービスは、適切なオプションよりも後で必要になります。 OpenLDAPは、RDBMSを含む任意のソースからデータを取り込むことができるシェルバックエンドもサポートしています。私はMySQLで使用しましたが、特定のLDAPスキーマをサポートする必要がある場合、最初にセットアップするのは少し面倒かもしれませんが、うまく機能します。
要約すると、LDAPは優れていますが、相互運用性と極端なスケーラビリティに固有の状況です。管理およびサポートするリソースが限られている場合は、面倒なサポートを行う価値はないかもしれませんが、UNIXでホストされるPOP/IMAP/SMTPやその他のサードパーティソフトウェア統合などのサービスを計画している場合は、確かに実行する価値があります（さらにはあなたの唯一の実行可能なオプションである）。
最後に、LDAPサーバーを実装する場合は、使用するLDAPサーバーに注意してください。それらはすべて同じように作成されているわけではなく、それらの間の違い（パフォーマンス、管理と構成の容易さの点で）は非常に顕著です。
OpenLDAPは非常に安全な方法であり、拡張性が高く、かなり使いやすいです。一部のアプリケーションは最適に動作します/特定のLDAPサーバー用の特定の構成ファイルが付属しています（たとえば、Solaris上の多くのソフトウェアはSun ONEディレクトリサーバーを使用していると想定しています）。これは、他の方法では使用したくない場合があります。 、または構成する豚である、十分にサポートされていないなど。
Microsoftは Active Directoryアプリケーションモード（ADAM）製品について説明しているTechNetの記事 を作成し、ディレクトリとデータベースの違いを比較するセクションがあります。以下は、サイトから直接取得したものです。
ディレクトリ
- 検索および読み取り操作用に最適化されています。
- オブジェクト指向の階層データ設計。ディレクトリ内のデータオブジェクトは、ユーザー、コンピューター、共有リソースなどのエンティティを表します。これらのデータオブジェクトは、コンテナ内で階層的に編成できます。
- スキーマを使用しません。
- レプリケーションおよび分散管理用に設計されています。
- オブジェクトおよび属性レベルまでの正確なセキュリティ。
- レプリケーションパートナー間のデータの整合性が緩い。
データベース
- 書き込み操作用に最適化されています。
- リレーショナルデータの設計。データは行と列のテーブルに編成されています。あるテーブルのデータを別のテーブルのデータにリンクできます。
- 標準化された拡張可能なスキーマを使用します。
- データの中央ストレージと管理用に設計されています。
- 精度が低く、行と列のレベルまでしかセキュリティがありません。
- トランザクション—データの整合性が保証されます。リレーショナルテーブル全体の参照整合性と、ファイルとレコードのロックによる同時実行制御。
LDAPの「L」はLightweightを表します。 LDAPの目標の1つは、使用と実装が比較的簡単になることです。ユーザーに関する情報を保存するだけの場合は、SQLを介してデータにアクセスするための完全な柔軟性（および潜在的な頭痛の種）は必要ありません。 LDAPによって提示される制限されたインターフェースはより簡単なはずです。これは、OSベンダーやすべてのアプリケーションベンダーを含むすべての人がLDAPを実装およびサポートする場合に重要です。
PS：必要に応じて、すべての情報をRDBMSに格納し、それにLDAPインターフェイスを提供することで、いつでもLDAPサーバーを実装できます:)
PPS：LDAPは、HTTPのようなプロトコルです。 RDBMSはアプリケーションであり、通常、SQLなどを実装するアプリケーションと考えられています。したがって、アップルとアップルを比較するには、LDAPとSQLまたはHTTPを対比する方がよいでしょう。
相互運用性。
LDAPディレクトリには、ユーザーを表す標準スキーマがあるため、名、姓、電子メールアドレスなどの一般的なフィールドは、さまざまなディレクトリ実装間で一貫して名前が付けられます。これは、RDBMSには当てはまりません。
LDAPは、通信プロトコルとクエリ言語の両方を定義します。これを、クエリ言語のみであり、各RDBMSが独自の通信プロトコルを実装しているSQLと比較してください。
そのため、ユーザーストアとしてLDAPディレクトリに簡単に「プラグイン」できるアプリケーションが多数あり、ユーザー管理を一元化できます。 （もちろん、ディレクトリの実装間には互換性の問題がありますが、ユーザーをアプリごとに別々のデータベースに保存するのと比較すると、これらは見劣りします）。
理由の1つは、（LDAPを使用する）多くのアプリでシングルサインオンを提供することです。