詳細な問題: 記事データ テーブルには、ユーザー uid またはユーザー名が保存されます。

uid またはユーザー名を記事データ テーブルに保存する必要がありますか?
記事表示ページ: ユーザー名著者が表示される必要があり、uid は著者のリンクに必要です。
いずれか 1 つだけが保存される場合、それぞれ記事では、別の情報を一度クエリする必要があります。
両方の種類の情報が保存されている場合、これまで多くの CMS ケースを見てきましたが、この方法で保存されたものはありません。 >
要約すると、どのように選択すればよいですか;
両方を保存する方が合理的だと思いますが、いくつかの cm を見た後、どちらか 1 つだけが保存されています。
これでは混乱します。


>

ディスカッションへの返信 (解決策) ストア uid

uid を入力して表示し、uid に基づいてユーザー名を取得することをお勧めします

uid を入力して表示し、uid に基づいてユーザー名を取得することをお勧めします

スペースを犠牲にしてオーバーヘッドを減らす方が合理的ではないでしょうか?

ですよね。関連するクエリだけですか?



uid を入力してから表示し、uid に基づいてユーザー名を取得することをお勧めします

ではありません両方のスペースを犠牲にして、オーバーヘッドを減らす方が合理的ではないでしょうか?

ユーザー名を変更できる場合は、複数のクエリを変更する必要があります。テーブルを変更するとき。

uid を入力するだけで、関連するクエリでユーザー名を見つけることができます。
両方を保存するのはあまりにも無駄で、少し冗長で不要です。
インデックスを uid に追加します。一度のクエリはそれほどコストがかかりません。結合テーブル クエリを使用せず、2 つの SQL を使用してナラティブを区切るよりもはるかに優れています。 🎜>

uid を入力して表示し、uid に基づいてユーザー名を取得することをお勧めします

両方のスペースを犠牲にしてオーバーヘッドを減らす方が賢明ではないでしょうか?

ユーザー名を変更できる場合は、変更する必要があります。変更するときは複数のテーブルを使用します。

ユーザー名は変更する必要が少なく、パフォーマンスの消費は短期的です。
ただし、ユーザー名は保存されません:
例: ユーザー名は記事リスト ページに表示する必要があります。 ; 1 ページに 30 個の記事がある場合は、30 個のクエリにユーザー名を掛けたものに相当します。
関連クエリの使用でもパフォーマンスが非常に高くなります。 ? ?
これは当然のことです
リレーショナル データベースはこのように設計されており、リレーショナル データベースに余分なオーバーヘッドはありません (使用しないと無駄です)
詳しく見てください。データベースパラダイム
では、ユーザー名の定義が重複しない限り、ユーザー名を保存する方が良いと思います。データベースへのクエリの操作が軽減され、プログラムの効率が一定まで向上します。エクステント

ユーザー名が変更可能なニックネームである場合は、uid のみを保存します
固定のログイン ユーザー名である場合は、ID と名前の両方を保存します
リレーショナル パラダイムによれば、ユーザー名は保存しないでください。

また、memcache などの非リレーショナルなものを使用し、uid=>username を使用して読み取ることもできます。

ユーザー名が表示される場合、ポイントやレベルを表示したり、テーブルを再度確認したりする必要がある場合があるため、uid を保存するだけで簡単に拡張できます。