データベースとテーブル管理

Question

私はWebアプリケーションを作成しており、拡張しようとしています。私のWebアプリケーションでは、ユーザーが管理者であるかどうかを追跡するための特権を含むユーザー用のテーブルと、ページの動的コンテンツセクション用の非常に小さなテーブルと、Webサイト上の「イベント」を追跡するためのテーブルがあります。

ウェブアプリケーションの作成にあまり経験はありませんが、専門家がウェブアプリケーション用のデータベースとテーブルのシステムをどのように作成するかについてはわかりません。私のWebアプリケーションでは、Webサイトのメンバーごと、さらにはメッセージングシステムまで、さらにユーザー設定を追加する予定です。私は現在、すべてのコマンドをクエリするMySQLデータベースを使用してPHPを使用していますが、必要に応じてこれを変更するつもりです。対人関係のメッセージや各ユーザーの特定のユーザー設定など、コンテンツを追跡するのに最適な方法は何でしょうか。私はいつでも複数のデータベースを保有したいですか？おそらく、各ユーザーごとに複数のテーブルを用意したいのですか？これがどのように行われているか、行われなければならないかについての情報は非常に役に立ちます。

質問の広さは残念ですが、私はテーブルの使い方についての私のアイデアがプログラマーの経験と同じではないと感じているので、このWebアプリケーションを改革したいと思っています。ありがとうございました！

Answer 1

を折り返し報告ここでは、あなたの質問に私の一見長く、うまくいけば、あまりにも複雑ではない答えです。私はあなたの質問すべてではないにしても、ほとんどをカバーしたと思います。

ウェブアプリケーションの場合、「ユーザー」と呼ばれるユーザーテーブル、「UserSettings」と呼ばれる設定テーブル、または同等のものと説明的なもの、「PrivateMessages」テーブルのメッセージを持つことができます。次に、必要な余分なデータを格納する子テーブルが存在する可能性があります。

ユーザーのセキュリティは、設計と実装が難しい場合があります。あなたはグループ単位でやりたいのですか（多くのユーザーを抱えて、より簡単に権限を管理できるようにする場合）、あるいは小さなユーザーベースのため個別に割り当てるだけですか？あなたは、ユーザ情報、設定、彼らはに割り当てることができるグループとそれらが正しく分離に割り当てられているを持つことができますこの方法

Users 
UserSettings 
UserGroups 
UserAssignedGroups 

：単独のセキュリティを強化するために、4つのテーブルで終わるだろう。これにより、適度な柔軟性が得られ、上記のDrSARのように標準化基準に準拠します。

メッセージには、ユーザー名ではなくユーザーIDでメッセージを保存してください。たとえば、PrivateMessagesテーブルでは、最も基本的な情報を格納するMessageID、SenderUserID、RecipientUserID、Subject、BodyおよびDateSentがあります。

SELECT * FROM PrivateMessages WHERE RecipientUserID = 123556 

あなたのメッセージのためのテーブルのリストは以下のようなことができます：

PrivateMessages 
MessageReplies 

PrivateMessagesテーブルことができますこの方法では、ユーザーが自分の受信したメッセージをチェックしたい場合、あなたは言ってテーブルを照会することができます親メッセージを格納し、その後MessageRepliesテーブルは後続の応答を格納することができます。 1つのテーブルにすべてを格納することができますが、トラフィックに応じて、おそらく1つのテーブルからすべてのメッセージと返信を取得するための再帰関数を記述することによって、2つのテーブルアプローチが簡単になります。

私があなただったら、私は鉛筆と紙で座り、自分のデータベースに記録したいものを書き留めておきます。そうすれば、あなたが保存したいものとの間にリンクを描き、どのように一緒に来るかを見ることができます。私が物事を視覚化しようとしているとき、それは私を助けます。

Answer 2

ウェブアプリケーションの範囲については、複数のデータベースは必要ありません。ただし、データを効率的に格納するには、複数のテーブルが必要です。

ユーザ設定の場合は、必ず別のテーブルを使用してください。ユーザーがログインしようとするたびにアクセス（=検索）されるため、「メイン」ユーザーテーブルは可能な限りリーンにしてください。ストアID、ユーザー名、パスワード（ハッシュされたもの）認証時にアクセスする必要があります。すべての余分な情報を別のテーブルに入れてください。そうすれば、あなたのログインは小さいテーブルだけを照会し、ユーザーが認証されると、そのIDを使用してセカンダリテーブルから他のすべての情報を取得することができます。

メッセージの大きさがより大きいため、メッセージを扱うのが難しくなる可能性があります。ユーザーごとに数十または数百もある可能性があります。アプリケーションのロジックに基づいてテーブル構造を設計する必要があります。各ユーザーの表は明らかに実現可能な解決策ではないので、一般的なメッセージ表を参照してください。ただし、管理可能なサイズに維持する手順を実装してください。たとえば、X日より古いメッセージを「アーカイブ」すると、別のテーブルに移動されます（ユーザーが古いメッセージに頻繁にアクセスする可能性が低い場合はうまくいきます）。しかし、私が言ったように、それはあなたのアプリケーションに依存します。

幸運を祈る！

Answer 3

Cristian Raduのコメントに沿って、データを別のテーブルに分割する必要があります。リーンユーザテーブルには、実際にはユーザごとに1つの一意のIDが必要です。この（ユニークな）キーは、セカンダリテーブルで繰り返される必要があります。それは外部キーと呼ばれます。明らかに、ユニークなキーが必要です。ユーザー名が一意であることが保証されている場合（つまり、メールアドレスでユーザーを識別する必要がある場合）、そのユーザー名を使用できます。ユーザー名が実名（Firstname Sirnameなど）である場合、その保証はなく、ユーザーIDを自分の鍵とする必要があります。同様に、あなたの投稿を含むテーブルは、誰がそれを書いたのかを示すユニークなユーザIDを持つフィールドを持つことができます（ただし必須ではありません）。

データベースの設計と正規化の概念について少しお読みください：//dev.mysql.com/tech-resources/articles/intro-to-normalization.html）正規表現のn番目の形式ではうんざりする必要はありませんが、この段階では、データベース設計を行う。

幸運と;-)