データベースの内部構造を公開するのは悪いと言われましたが、比較的高プロファイルのサイトがたくさんあることに気付き始めました。 ChartboostとServerDensityは両方とも、URLにMongoDB文書_id
フィールドを公開しています。データベースの内部構造を公開するのは悪いですか?
誰かが、なぜそれが悪いのかについていくつかの光を放つことができますか?私が考えることができる唯一のことは、人間が読めるURLではないのでSEOにとって悪いことですが、これは本当ですか?
データベースの内部構造を公開するのは悪いと言われましたが、比較的高プロファイルのサイトがたくさんあることに気付き始めました。 ChartboostとServerDensityは両方とも、URLにMongoDB文書_id
フィールドを公開しています。データベースの内部構造を公開するのは悪いですか?
誰かが、なぜそれが悪いのかについていくつかの光を放つことができますか?私が考えることができる唯一のことは、人間が読めるURLではないのでSEOにとって悪いことですが、これは本当ですか?
「データベースの内部を公開する」とは、データベースサーバーをインターネットに公開したり、ユーザーに任意のクエリを実行させるようなことを理解しています。このことは間違いなく悪いことです。また、データベーススキーマを何らかの形で公開すると、悪意のあるユーザーがこれを使用してメリットを得ることができます。
URLにオブジェクトIDを使用すると問題ありません。人間はとにかくURLを記憶しておらず、ポストへのリンクがポスト・スラッグかポスト・イドかどうかは検索エンジンが気にしない。
さらに、データベースのID-sをURLに表示します。とにかく、何らかの形でリソースを特定する必要があります。基本的には、すべての単一のサイトがURL(通常はPK)で何らかの識別情報を使用します。なぜ彼らはMongoDbを使うと思いますか? Long PKの代わりにGUIDを使用したデータベースでも可能です
データベーススキーマを表示しても、SQLインジェクションから保護されるまでは何も起こりません。
しかし、SOのIDはDBに固有ではありません。mongoDB _id – UpTheCreek
DB固有のIDは何ですか?私はサロゲートやナチュラルPKをデータベースから特別な「非特定」IDに変換する理由は見当たりませんID – Anton
Db固有。デフォルトでは、自動インクリメント、guid、または他の一般的に使用されるDB識別子ではありません。デフォルトのMongoDB ObjectIdには、レコードが作成された日付、ドキュメントを作成したマシンの識別子、およびアプリケーションの背後で使用されているdbを特定する必要があります。もちろん、あなたは_idを独自の識別子型に置き換えることができます。その場合はSOと同じ状況になります。 – UpTheCreek