2

PHP と MySQL を最適化しようとしていますが、SQL データベースに関する私の理解はせいぜいお粗末です。ユーザーがさまざまな種類の投稿 (画像/ビデオ/テキスト/リンク) を作成できる Web サイト (主に学習目的) を作成しています。

これが私が保管しているものの基本です

  1. Auto - int (キー インデックス)
  2. ユーザー ID - varchar
  3. 投稿 ID - varchar
  4. 投稿タイプ- varchar (YouTube、vimeo、画像、テキスト、リンク)
  5. ファイル名- varchar (元の画像名またはリンク タイトル)
  6. ソース- varchar (外部リンクまたはファイル名 + ext)
  7. タイトル- varchar (ユーザーが選択した投稿のタイトル)
  8. メッセージ-テキスト(ユーザーの実際の投稿)
  9. 日付- int (UNIX タイムスタンプ)

投稿ID（ユーザー情報など）で取得する他のテーブルに投稿に関連する他のデータを保存していますが、これが情報を保存する方法であるかどうかは本当に疑問です。私はPDOを使用しますが、私は'残念ながら、この形式は非常に遅いだけかもしれません。

投稿情報を別の形式で保存する意味はありますか? 過度に大きなテーブルは必要ないので、パフォーマンスの観点から、いくつかの情報を blob/binary/xml/json として保存する必要がありますか?

PHP/MySQL の最適化に関する適切なリソースが見つからないようです。私が遭遇するほとんどの情報は、5 ～ 10 年前のもの、料金を支払わなければならないコンテンツ、レベルが低すぎる、または単純なドキュメントであり、30 分以上注意を引くことができない傾向があります。

4

3 に答える 3

3

データベースは「データ」を保存するために作成されており、データをすばやく取得できます。他のものに切り替えないでください。データベースに固執してください。

写真やビデオをデータベースに保存しないようにしてください。それらをディスクに保存し、それらへの参照をデータベース テーブルに保持します。

最後に、データベースの正規化に追いつくと、データベースを最適な状態にするのに役立ちます。

于 2012-09-06T07:36:30.657 に答える
1

あなたが持っているものは大丈夫に見えますが、インデックスとキーに関する重要な部分を見逃しています.

まず、主キーがフィールド 1 になると想定しています。問題ありませんが、userID、PostID、Date にインデックスを貼り付けて、おそらく UserID、Date にコンポジットを貼り付けてください。

次に、これらに検索機能を追加する予定はありますか? その場合、全文検索を有効にする必要があるかもしれません。

JSON などにデータを保存しようとして、いじくり回さないでください。すっきりシンプルに収納。一番やりたくないことは、データベースからフィールドを抽出して、中身を確認することです。データベースがうまくいかない場合、それは悪い設計です。

その点では、大きなテーブルに問題はありません。それらが適切に索引付けされている限り、小さなテーブルまたは大きなテーブルは、それにアクセスするという点でほとんど違いがありません (巨大で不適切に作成された SQL 結合を除く)。

編集:主キーは、ある種の一意の列で行を識別する素敵な方法です。したがって、行を削除する場合、例で aを指定すると、 ID=6 を持つことができるのは 1 つの行だけなので、これは1 つのdelete from yourTable where ID=6行だけを削除することがわかります。

一方、インデックスは、特定の情報がテーブル内のどこにあるかをデータベースが知るためのチートシートのようなものであるという点で、キーとは異なります。たとえば、UserID 列にインデックスがある場合、クエリで userID を渡すと、データベースはテーブル全体を調べる必要はありません。インデックスを見て、そのすべての行の場所を認識します。ユーザー。

複合インデックスは、これをさらに一歩進めています。UserID と ContentType の両方のデータを常にクエリする必要があることがわかっている場合は、複合インデックス (1 つのインデックス内の両方のフィールドのインデックス) を追加できます。データベースは、テーブル全体をふるいにかける必要はなく、適切なコンテンツ タイプを見つけるためにすべてのユーザーの投稿をふるいにかける必要もなく、両方の列を使用してクエリで指定したデータのみを返します。

現在、インデックスはサーバー上で余分なスペースを占有するため、そのことを覚えておいてください。ただし、テーブルが大きくなった場合 (これはまったく問題ありません)、効率の向上は驚異的です。

于 2012-09-06T07:36:48.190 に答える
1

現時点では、当面は RDMS を使用してください。PHP と MySQL に慣れたら、後で NoSQL や MongoDB などを学習する必要があるかもしれませんが、すべてのものには目的があるため、現在の目的のためには、これはまったく正しいことであり、速度が低下することはありません。あなたのテーブルスキーマは、ほとんど変更されていないようです。

ユーザーIDと投稿IDは整数になり、このテーブルは投稿だと思うので、投稿IDは自動インクリメントされ、主キーになります。

他に、ファイル名とソースの 2 つのフィールドを使用していることです。ファイル名はアップロードされるファイルの名前になりますが、ソースがファイルの完全なパスを意味する場合、DB は完全なパスを保存する場所ではないことに注意してください。PHP 関数からパスを生成します。DBにないたびにそのパスにアクセスします。それ以外の場合は、パスを変更する必要がある場合、オーバーヘッドが大きくなります。

また、blob などについて質問されました。ファイルを db ではなくファイル システムに保存する方がよいことに注意してください。ただし、blob などのこれらのフィールドは、ファイルを DB テーブルに保存する場合に適しています。ここではお勧めしません。

于 2012-09-06T07:47:07.157 に答える