1

次の問題があります。データベースにアイテムのリストを保存し、それらをWebページに表示しています。Webページ上のすべてのアイテムにIDまたはクラスを割り当てる必要があります。最も簡単な方法は、データベースにあるのと同じIDを割り当てることです。次に例を示します。

データベース

ID  |  Name
----+-----------
1   |  Apple
2   |  Orange
3   |  Banana

HTML

<ul>
  <li id="1">Apple</li>
  <li id="2">Orange</li>
  <li id="3">Banana</li>
</ul>

明らかな問題は、HTMLIDが数字で始まらないことです。そこで、IDにプレフィックスを付けることを考えました。たとえば、次のようになります。

<ul>
  <li id="f1">Apple</li>
  <li id="f2">Orange</li>
  <li id="f3">Banana</li>
</ul>

ただし、これによりHTMLとデータベースの間に不整合が生じ、オブジェクトの操作がより複雑になります。これを解決するには、データベースに新しい列を追加する必要があります。

ID  |  Name     |  HTML_ID
----+-----------+---------
1   |  Apple    |  f1
2   |  Orange   |  f2
3   |  Banana   |  f3

新しいアイテムを追加するたびにデータベースにHTML_IDを手動で入力する必要があるため、これも理想的な解決策ではないようです。また、HTML_IDが常に一意であることを確認する必要があります。

Web開発をしているときに、人々はこの問題にかなり頻繁に遭遇すると確信しています。上記の例よりもこれを処理するためのより良い方法があるかどうか疑問に思いました。

4

3 に答える 3

1

確かに、データベースにHTMLIDを保存するべきではありません。ページをレンダリングする時点でプレフィックスを追加する場合の問題は何ですか？もちろん、他の明らかな質問は、なぜ各リストアイテム要素に異なるIDを割り当てる必要があるのか​​ということです。

于 2012-07-29T13:40:24.097 に答える
1

HTMLに挿入する前にその場でプレフィックスを追加しid、データベースを検索する前にプレフィックスを削除します。よりクリーンなデータベースとよりクリーンなコードのどちらかを選択するときは、よりクリーンなデータベースを選択してください。

id接頭辞付きのデータベースを保存する：

  1. 本質的に冗長なデータのためにテーブルのスペースを浪費します。データが大きいということは、事実上「小さい」キャッシュを意味します。
  2. 検索したいので、インデックスが必要です。これは、クエリに使用できなくなったインデックスに追加されたインデックスですが、一意性を強制するために必要です。idすべてが同じである場合、インデックスを追加するたびにINSERT / UPDATE / DELETEが遅くなり、テーブルがクラスター化されている場合は非常にコストがかかる可能性があります*。また、「より大きなデータ」と見なされ、キャッシュが「より小さく」なります。

DBMSが適切なメカニズム**をサポートしている場合、実際にフィールドを物理的に格納する必要はありません。DBMSはその場でフィールドを計算できるため、ポイント（1）は無関係になります。

ただし、それでもインデックスを作成する必要があるため、ポイント（2）は引き続き関連性があります。

*一部のDBMSでは、クラスタリング（MySQL / InnoDB）をオフにする選択肢さえありません。

**インデックス付きまたはインデックス付きのVIEWが可能な計算列など。

于 2012-07-30T09:24:05.093 に答える
0

IDが競合しない限り、一度に複数のテーブルを使用することはできないため、生のデータベースIDを使用することは直感的には悪い考えのように思われます。答えは、IDをHTML用の何かに書き直すための賢明な方法を決定することです。これを行うための堅牢な方法は、テーブル名とIDを連結することです。これは、競合するIDを持つことができないことを意味します。これの欠点は、データベースに関する多くの情報をページに配置することです。これは、セキュリティ上の懸念と見なされる可能性があります。

于 2012-07-29T13:39:03.713 に答える