0

これは、Web ページからデータを保存するベスト プラクティスをどのように実行するかという問題です。texts/image-urls/links などのように。

Web ページを作成できる CMS があります。ここでは、テキストの編集/画像のアップロードを行うことができます。将来的には、「新しい要素を追加」したり、a-tags へのリンクを追加したりすることもいいでしょう。

優れたパフォーマンスを備えた堅牢で柔軟なソリューションが必要です。このデータの取得/受信の両方で。

更新してデータベースに保存できる各ページに約 25 の要素を持つ 1000 ページがあるとします。

代替案 1)

これらのページの要素ごとにテーブルと 1 つの列を作成します。たとえば、title_1、title_2、image_1、image_2 などの列を作成します。

ここには、更新できる一連の列があり、これらは Web ページで使用できます。

代替案 2)

列 (id、namespace、page_id、data) を含む 1 つのテーブルを作成します。

そして、ページの各要素に対して、page_id に関連する名前空間を追加して、データ出力を一意にします。データには、あらゆる種類の情報を追加できます。テキスト、リンクなど

この問題の良い解決策として何を提案しますか? もちろん、他の選択肢にも対応しています。

ありがとう！

4

1 に答える 1

0

実際に要素IDが何らかの形で比較できる場合は、要素ID/またはタイプを識別する列を追加して、オプション2をお勧めします。つまり、アンカー テキスト (たとえば) が常に要素 ID = 4 として格納されている場合、複数のドキュメント間でアンカー テキストを比較できるように、要素 ID = 4 が必要になる場合があります。

一方、(これは私がより可能性が高いと考えるシナリオです)、1 ページに 1 ～ 25 の要素があり、それぞれが異なる場合があります (たとえば、ドキュメント 1 には 3 つのアンカー テキストと 4 つの画像があり、ドキュメント 2 はアンカー テキストが 1 つあり、画像がないなど）、要素タイプに関する情報を少し格納する element_type_id テーブルを追加することは理にかなっています。これは、複数のドキュメント間で画像を比較したり、複数のドキュメント間でテキストをアンカーしたりすることに関心があることを前提としています。

考慮すべきもう 1 つの点: 同じ要素が何度も何度も表示される可能性が高い場合は、ルックアップ テーブルを使用してそれらの要素を効果的にパラメーター化する方が実際には理にかなっています。したがって、基本的には、各 (たとえば) 一意のアンカー テキストを 1 つのテーブルに格納し、実際のデータ テーブルでその ID を参照します。

もう1つ追加する場合：SOは、あなたが求めている特定の質問に最適な場所ではないかもしれません. 私はそれについて完全には確信が持てず、おそらく私が間違っているかもしれません...しかし、Stack Exchangeネットワークを調べて、他のフォーラムがあなたの質問のタイプをより密接に扱っているかどうかを確認します. 少なくとも、あなたの質問はかなり漠然としており、「このデータの取得/受信の両方で優れたパフォーマンスを{持つ}堅牢で柔軟なソリューション」を達成するという目標を達成することを私は見ています。SO に関するアドバイスを求めるだけでは達成できない可能性があります。たくさんありますそれはデータ アーキテクチャに入ります。確かに、私がこれを自分で設計する上で重要だと考える詳細の多くは、あなたの質問には含まれていません。そして、それらの詳細が何であるかわからない場合、SOが本当にそれらを学ぶのに最適な場所であるかどうかはわかりません. https://softwareengineering.stackexchange.com/がこの質問により適している と思います。

あくまで私見ですので、間違っているかもしれません。いずれにせよ、データベースの標準形 ( http://www.bkent.net/Doc/simple5.htmまたは Google it)について少し学ぶことを検討し、構築に必要な設計上の考慮事項の種類について少し調査します。データベース (これに関する古くても優れた SO 記事はこちら:データベースを設計する際の最も重要な考慮事項は何ですか? )

于 2014-07-12T01:22:48.353 に答える