いくつかの分析値を保存したいと思います。たとえば、ユーザーがアクションXを実行した回数や、過去1日にログインしたユーザーの数などです。
このためのベストプラクティスは、既存のアプリケーションデータベースに別のテーブルを追加することでしょうか?または、ここに新しいデータベースを追加しますか?2番目のオプションは少しやり過ぎだと思います。
いくつかの分析値を保存したいと思います。たとえば、ユーザーがアクションXを実行した回数や、過去1日にログインしたユーザーの数などです。
このためのベストプラクティスは、既存のアプリケーションデータベースに別のテーブルを追加することでしょうか?または、ここに新しいデータベースを追加しますか?2番目のオプションは少しやり過ぎだと思います。
それは完全にあなたのビジネス/セキュリティ/公益のニーズ、ユースケース、そして資金に依存します。
たとえば、分析によって、「この小さな公開Wikiを読んでいる匿名の人の数を計算する」という意味の場合、テーブルはおそらく問題ありません。そのwikiが大きくなると、パフォーマンス上の理由から別のDBが必要になる場合があります。
ただし、分析DBにサイトメンバーに関する情報(特に公開Webサイトに直接保存する必要のない情報)が含まれる場合は、データを保護するためにすべての合理的な予防措置を講じる法的責任があります。これは、公開サイトのDBではなく、別のビジネス内部DBに保存することを意味する場合があります。
少なくとも、Webアプリで分析するために、個別のDB接続設定、個別の接続、および個別のカーソルを用意して、後でそれらを個別のDBに簡単に分割できるようにする必要があります。これは多くの場合、Webアプリの読み取りと書き込みを分離するために行われるため、行き詰まっている場合は、その例を見つけることができるはずです。
特定の小さなサイトの負荷を超えると、パフォーマンスのために別のDBにそれが必要になります。とにかくパフォーマンスのために構築された、ある種の分散型の水平方向にスケーラブルなDBを使用している場合を除きます。
別のデータベースを使用してください。これにより、スキーマがクリーンに保たれ、データベースユーザーとそのアクセス権限の管理が容易になり(テーブルごとの権限が不要になるため)、その道を進む必要がある場合にレプリケーションの管理が容易になる可能性があります。
既存のデータベースに別のテーブルを追加するだけです。別のデータベースを追加する場合は、1つのデータベースから別のデータベースに同時に切り替えるmysql_connect()
必要があります。つまり、他のデータベースに接続する前に、前のデータベース接続を閉じる必要があります。少し時間がかかります。少し忙しい