1

私はデータベース設計に少し慣れていないので、テーブルに何を格納する必要があり、後でサーバーで処理できるテキストフィールドにマークアップ言語で何を格納する必要があるのか​​疑問に思っています。私の傾向は本質的にすべてのテーブルを作成することですが、mediaWikiのような多くのアプリケーションがマークアップを使用してデータを大きなテキストフィールドに格納していることに気づきました。これは、データベースクエリの量とテーブルのサイズを制限することで時間を節約しますか？または、サーバー側の処理に時間がかかりますか？

私のページ構造は次のとおりです。

Page contains:
id
page_image_id
user_id
title
path
deleted

Page has many Sections

-

Section contains:
id
page_id
position

Section has many Paragraphs
Section has many Images
Section has many Page_Links

-

Paragraph contains:
id
section_id
body_text
position

-

Image contains:
id
section_id
user_id
image_path
description
position

-

Page_link contains:
id
page_id
section_id
description
position

10万ページ以上に達する可能性を念頭に置いてデータベースを設計するのが好きです。最後の3つのテーブルは、すぐに大きくなる可能性があることに注意してください。そのすべての情報をセクションテーブルのマークアップに格納してから、サーバー側のコードを使用して情報を処理する方が効率的でしょうか。または、データベースクエリの速度を過小評価していて、そこにあるデータを操作する準備ができているので、上記の方が効率的ですか？テーブルの作成をやめてマークアップを使用する必要があるポイントはありますか？

4

2 に答える 2

1

この問題全体は、データ管理の観点から見たアトミックとは何かということに要約されます。

つまり、個々の段落やその他のページ要素がデータベースにある間に、それらを照会したり変更したりする必要がありますか?

  • はいの場合、あなたは正しい軌道に乗っています。データベース レベルでの細かい粒度により、個々のデータの各部分にインデックスを付けて取得し、他の部分を邪魔することなく 1 つの部分を変更することができます。
  • そうでない場合は、ページ全体を 1 つのフィールド (おそらく BLOB または CLOB) に格納します。アプリケーション レベルで(たとえば) 個々の段落を処理するかどうかは問題ではありません。常にデータベースからページ全体をフェッチする(そして常にページ全体をデータベースに書き込む) 場合、それはアトミック ピースとして格納する必要があります。データベース内のデータ。
于 2013-03-16T11:03:38.513 に答える
1

したがって、そのような場合には正しい答えも間違った答えもありません。

通常、考える必要があるのは、作成している結合の数、インデックスを作成する必要がある列などです。

私が通常やらないことは、正規化された方法で行き（あなたが行った）、ある種のプロファイリングを実行して、クエリが許容できるほど速いか遅いかを確認してから、設計を変更することを考えます。

通常、インデックスを作成すると、DB クエリが非常に高速になります。ただし、クエリのために結合するテーブルが増えるほど、処理が遅くなる可能性があります。これらは単なる大まかなガイドラインです。

于 2013-03-16T04:59:09.297 に答える