mongoDB 、express、および Node.js を使用したブログで、著者は、プロパティ名を短くすることをお勧めします。
....mongoDBでよく報告される問題は、ディスク上のデータのサイズです...すべてのレコードにすべてのフィールド名が保存されます....これは、多くの場合、プロパティを持つ方がスペース効率が高いことを意味します'title' や 'body' ではなく 't' や 'b' などですが、混乱を避けるために、本当に必要でない限りこれは避けます。
私はそれを行う方法の解決策を知っています。これが本当に必要になるのはいつですか？
ドナルド・クヌースを引用するには：
時期尚早の最適化は、プログラミングにおけるすべての悪 (または少なくともその大部分) の根源です。
ただし、最も賢明で、保守しやすく、論理的なアプリケーションを構築してください。次に、パフォーマンスまたはストレージの問題がある場合は、パフォーマンスが満足のいくものになるか、収穫逓減の法則によりそれ以上最適化しても意味がなくなるまで、最も大きな影響を与えるものに対処します。
特定の設計上の決定 (長いプロパティ名など) の影響が不明な場合は、プロトタイプを作成して、さまざまな仮説をテストします (たとえば、「プロパティ名を短くすると多くのスペースが節約される」など)。テストの結果が決定的であるとは思わないでください。
結論: 意味が残るようにコンパクトに保ちます。
これは必ずしも一文字の名前に短縮する必要があるとは思いません。とにかく、それらをできるだけ短くする必要があり、快適に感じます。ユーザー名が {FirstName, MiddleName, LastName}であるとしましょう。 name:{first, middle, last}を使用することもできます。快適に感じる場合は、name:{f, m,l} で問題ないかもしれません。
短い名前を使用する必要があります: ディスク容量やメモリを消費するため、アプリケーションが多少遅くなる可能性があります (メモリに保持するオブジェクトが少なくなり、サイズが大きくなるため検索時間が遅くなり、データのシークに時間がかかるためクエリ時間が長くなります)。
優れたスキーマ ドキュメントは、t がタイトルではなく町を表すことを開発者に伝えることができます。スタックによっては、ヘルパー utils を使用してマッピングすることで、開発者がこれらのショートカットを操作できないようにすることさえできる場合があります。
最後に、スキーマ名をいつ、どのくらい短縮するべきかについてのガイドラインはありません。環境と要件に大きく依存します。ただし、すべてを説明した優れたドキュメントを提供したり、開発者や管理者の生活を楽にするユーティリティを提供したりできる場合は、コンパクトに保つことをお勧めします。いずれにせよ、管理者は mongodb と直接対話する可能性が高いため、適切なドキュメントを見逃すことはできないと思います。
詳細な xml を使用している場合は、カスタム名でそれを改善しようとすることが非常に重要になる可能性があります。SERVER-863 チケットのユーザー コメントは、彼のケースについて次のように述べています。私は ' 外部で定義された XML オブジェクトを冗長な名前で保存しています。フィールド名はおそらく、合計レコード サイズの 70% です。そのため、フィールド名のトークン化は、I/O とメモリ効率の両方の点で大きなメリットになる可能性があります。