私はいくつかの分析図を保存したいと思います。たとえば、ユーザーがアクションXを実行した回数や過去の日にログインしたユーザーの数など分析のための新しいデータベースまたは新しいテーブル?
これは、既存のアプリケーションデータベースに別のテーブルを追加するのがベストプラクティスですか?または、ここに新しいデータベースを追加しますか?私は第二の選択肢は少し過剰なものになると思っています。
私はいくつかの分析図を保存したいと思います。たとえば、ユーザーがアクションXを実行した回数や過去の日にログインしたユーザーの数など分析のための新しいデータベースまたは新しいテーブル?
これは、既存のアプリケーションデータベースに別のテーブルを追加するのがベストプラクティスですか?または、ここに新しいデータベースを追加しますか?私は第二の選択肢は少し過剰なものになると思っています。
それはあなたのビジネス/セキュリティ/公共の利益のニーズ、ユースケース、および資金調達に完全に依存します。
たとえば、アナリティクスで「この小さな公開Wikiを読んだ匿名の人たちの数を計算する」という場合、おそらくテーブルはうまくいくでしょう。そのwikiが成長すれば、パフォーマンス上の理由から別のDBが必要になるかもしれません。
しかし、アナリティクスDBにサイトメンバーに関する情報(特に公開ウェブサイトに直接保存する必要のない情報)が含まれている場合は、データを保護するためのすべての妥当な予防措置を取る法的責任があります。これは、公開サイトのサイトDBではなく、別のビジネス内部DBに格納することを意味します。
少なくとも、個別のDB接続設定、別々の接続、およびウェブアプリケーション内のアナリティクス用の個別のカーソルが必要です。後で別のDBに分割するのは簡単です。これはしばしばwebappsの読み書きを分けるために行われるので、あなたがいなくてもそれを見つけることができます。
特定の小さなサイトの負荷を過ぎると、パフォーマンスに関係なく、別のDBに格納することになります。いずれにしても、パフォーマンスのために構築された分散型の、水平方向に拡張可能なDBを使用している場合を除きます。
別のデータベースを追加すると、あるデータベースから別のデータベースに切り替えると同時にmysql_connect()
を処理する必要があることを意味します。接続する前に以前のdb接続を閉じる必要があります。それはちょっと忙しいです
まだ 'mysql_connect'を使用しているのであれば、本当にMySQLiについて知る必要があります。また、MySQLiを学びながら同時に複数のMySQL接続を開くことができます。 –
@daknok_tあなたが言ったことはまったく正しいですが、私はちょうど一般的な事を話しています。 mysql_pconnect'persistent connectを使用することもできます – diEcho
別のデータベースを使用してください。スキーマをよりきれいに保ち、テーブル単位の権限が不要なため、データベースユーザーとそのアクセス権限を管理しやすくなり、そのような状況に陥る必要が生じた場合でもレプリケーションを管理しやすくなります。
これは広範で、実際にはアプリケーションによって異なります。あなたのアプリ/トラフィック/などを記述することでこれを少し絞り込むことができますか? –