9

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

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

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

4

5 に答える 5

5
  • LDAPはネットワーク管理者にとっては高レベルであり、ソフトウェア開発者にとっては低レベルであると常に思っていました。それらのどちらもそれに快適ではないようです。
  • ほとんどすべてのエンタープライズアプリケーションはリレーショナルデータベースを使用するため、データソースをもう1つ追加すると、アプリケーションの可用性と信頼性が低下するという認識があります。
  • LDAPでカスタムスキーマを作成するための障壁は依然として高いです。LDAPサーバーでは、スキーマファイルをスキーマディレクトリに配置する必要があります。通常、rootまたは管理者権限でLDAPサーバーを再起動します。一方、現在のORMは、アプリケーションの起動時にリレーショナルデータベーススキーマを作成、更新、または検証できます。
于 2009-04-04T12:22:54.900 に答える
4

個人的にはLDAPがディレクトリだからだと思います、データベースではありません。ディレクトリは、人とそれに関連するデータを検索するのに適していますが、リレーショナル性の高いデータを追跡するのには特に適していません。これは、残りのデータの多くがどのように見えるかを示しています。実際、LDAPの使用は、実際には「人」データのフロントエンドとして使用され、多くのデータストリームを単一のディレクトリビューにマージします。バックエンドデータベースには、残りの機関データとともに「人」データが残っており、マージされた「人」データを簡単に検索できるように、フロントエンドとしてLDAP（この場合はADAM）のみを選択しています。このデータにアクセスする手段としてWebサービスに移行しているので、LDAPルートを続行することが理にかなっているとは言えません（更新されていない既存のサービスをサポートする場合を除く）。

于 2009-04-04T12:34:15.903 に答える
3

私たちは、6,500 万の LDAP レコードを持ついくつかの企業のために作業を行いましたが、レコードはどれも人用ではありませんでした。

データは、主に次のようなデバイスに関するさまざまな項目でした: * DHCP * DNS * Mac アドレス * 場所 * SN * ブランド * モデル * など....

-ジム

于 2009-04-07T14:10:11.403 に答える
2

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

現在、他のLDAPデータへのアクセスを必要とする組織向けに特別に作成された内部アプリケーションは別の話です。しかし、それらは商業的に販売されていないため、明らかにそれらについてはあまり耳にしません。

于 2009-04-04T12:09:22.577 に答える
0

LDAP は高速で頻繁な読み取り用に高度に最適化されていると思いました。トランザクション システムに対応できるとは思えません。

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

于 2009-04-04T15:50:03.933 に答える