2

スタックオーバーフローでは完全に許可されていないアイデアの共有が含まれるため、これは削除される可能性がありますが、それでもその前に、堅実なプログラマーからアイデアを得ることができれば、それは私にとって有利な状況になります

データベースに格納されているクラスStudentがあり、このクラスにfavoriteTeachersというリストプロパティがあるとします。このリストはシステムによって常に更新され、教師のIDが含まれます。

また、クラスTeacherもデータベースに保存されており、同様にリストプロパティfavouriteStudentsがあります。それは再び絶えず更新され、学生のIDを含みます。

私たちのシステムでは、学生が関数（たとえばnotMyFavoriteTeacher）を呼び出すときに、システムは以下の変更を適用する必要があります。

  1. favouriteTeacherリストから指定された教師のIDを削除します
  2. 指定された教師のお気に入りの生徒リストから生徒のIDを削除します

更新された行数がデータベースを使い果たす可能性があることを考慮しようとしたので、user_id、teacher_idとして別のテーブルに生徒をお気に入りの教師とマッピングする代わりに、列を作成し、教師IDを含む文字列を格納しました。コンマ。（例：「1,2,14,4,25」）。先生にも同じことが言えます。

ただし、この関数を呼び出すと、別の問題も発生します。この操作を実行するには、文字列をリストに変換し、線形検索で要素を見つけてから削除し、後でリストを文字列に変換してdbにプッシュバックする必要があります。また、教師クラスの他の操作も行う必要があります。文字列方式を適用しないと削除しやすくなりますが、削除と加算の操作は1日2k回程度なので、別々のテーブルを使うのは現実的ではないと思いました。

操作回数を減らすためにお願いしたいのですが、効率が上がるようなデータ構造を選べますか？

4

3 に答える 3

3

リレーションを配列として 1 つの列に格納することは、第 1 正規形に違反するため、正当な理由がない限り行うべきではありません。さまざまな形式の非正規化によって、場合によっては効率が向上する可能性がありますが、このケースはその 1 つではないと思います。さらに悪いことに、参照整合性を強制する際にデータベースから何の助けも得られません。また、一部の操作では、行スキャンが保証されます。教師を削除する場合、すべての生徒のすべての行を調べて、各生徒のお気に入りリストから教師を削除する必要があります。生徒を削除する場合も同様です。

リレーショナル データベースは、行を他の行にリンクするように設計および構築されています。彼らがやろうとしていることをやらせないようにするには、非常に正当な理由が必要です。先に進んで適切なリレーショナル スキーマを設計する必要があります。実際の測定で遅すぎることが示された場合にのみ、そのパフォーマンスについて心配する必要があります。

于 2012-09-26T10:21:43.213 に答える
0

RDBMSを文字列のリストとして保存することにより、RDBMSによって提供されるすべての利点が失われます。Student_idとお気に入りのteacher_idを使用して別のテーブルを作成します。メインテーブルに結合する前に、フィルタリング条件（学生または教師のいずれか）を適用します。

于 2012-09-26T12:30:06.603 に答える
0

まず第一に、お気に入りの教師/生徒の ID をカンマ区切りの文字列として格納するというあなたの選択がわかりません。カンマ区切りの値の場合、または StudentId と teacherId 構造を持つテーブルの場合、正確に 2 行を実行するためです。更新/削除 (最初は favoriteTeachers テーブルで、2 番目は favoriteStudent テーブルで)。

ただし、現在のデータ構造を考慮してパフォーマンスを最適化する 1 つの方法は、カンマ区切りの文字列を並べ替えておくことです。行の形成そのものから、「1、5、7、15」のようにコンマで区切られたIDを保持してください。このように、リストに変換すると、バイナリ検索を実行でき、n ではなく Log(n) 時間がかかります。

于 2012-09-26T10:23:26.193 に答える