LDAPをユーザー以外の中央リポジトリとして使用している企業はなぜですか？

Question

大企業では、ユーザー情報の中央リポジトリにアクセスするためにLDAPを使用しましたが、inetOrgPersonから派生していないobjectClassesを含むようにスキーマを拡張する努力はほとんどありませんでした。

MicrosoftのActive Directoryは広範なスキーマ拡張を行いますが、商用製品はLDAPの機能をほとんど使用していません。

これは、ほとんどのLDAP開発者がユーザーを超えてモデル化する方法を知らないためですか？その中で価値を見つけても、それについて深く考えなかっただけですか？それを試してパフォーマンスの問題に遭遇しましたか？ l

Answer 1

私たちは6500万のLDAPレコードを持ついくつかの企業のために仕事をしましたが、誰のためのレコードもありませんでした。

データは主に含むデバイスのための様々なアイテムだった： * DHCP を* DNS * Macが *場所 * SN *ブランド *モデル *など....

をアドレス - ジム

Answer 2

これは、A）LDAP（SQLよりもはるかに高い）で作業することの複雑さと、B）製品が完全に結びついているという事実によるものだと思います。つまり、LDAPを実行している大規模な組織外の市場は存在しません。より少ないお金と労力で、私はどこでも働くアプリを作ることができました。

内部他のLDAPデータにアクセスする必要のある組織専用のアプリケーションは別の話です。しかし、商業的に販売されていないので、あなたは明らかにそれについて聞くことはありません。

Answer 3

• 私は常にLDAPは、ネットワーク管理者やソフトウェア開発者のための低すぎるレベルのため高すぎるレベルだと思ってきました。それらのどちらもそれに匹敵するものではないようです。
• ほとんどすべてのエンタープライズアプリケーションがリレーショナルデータベースを使用するため、1つ以上のデータソースを追加すると、アプリケーションの可用性と信頼性が低下するという認識があります。
• LDAPでカスタムスキーマを作成する障壁は依然として高いです。 LDAPサーバーでは、スキーマ・ファイルをスキーマ・ディレクトリーに置く必要があります。通常は、rootまたは管理特権でLDAPサーバーを再始動します。現行のORMは、アプリケーションの起動時にリレーショナル・データベース・スキーマを作成、更新または検証できます。

Answer 4

個人的には、LDAPはディレクトリであり、データベースではないと思います。ディレクトリは人とその関連データを検索するのに適していますが、他の多くのデータのように非常に関係性の高いデータを追跡するのにはあまり適していません。実際、LDAPの使用は実際には "人"のフロントエンドとして - データストリームを単一のディレクトリビューにマージします。バックエンドデータベースには他の機関のデータと同様に "人"のデータが残っており、マージされた "人"データを便利に参照できるようにLDAP（この場合はADAM）をフロントエンドとして選択しています。このデータにアクセスする手段としてWebサービスに移行しているので、（更新されていない既存のサービスをサポートすることを除いて）LDAPルートを続行することが合理的であるとは確信していません。

Answer 5

LDAPは高速で頻繁に読み込みが行われるように高度に最適化されていると思っていました。私は彼らがトランザクションシステムのために拡大するとは思わない。

SQLでのリレーショナルモデルとその表現は強力なものです。私はそれがLDAPやオブジェクトデータベースに簡単に取って代わられるとは思わない。