ユーザーが毎月データを入力する Web サイトを作成しています。このデータは、日付キーを使用して mysql データベースに保存されるため、日付で取得できます。このデータを閲覧するときに、ユーザーごとに個別のテーブルを用意する方が簡単で人間が読みやすいですが、それを行うのは悪い考えだと確信しています。誰でもこれを確認し、他の解決策を提供できますか?
3 に答える
1
なぜこれをしたいのですか？SQL はデータをフィルタリングします...たとえば、当月のデータを取得するには:
select col1, col2, col3 from tbl1 where date_format(date_col, '%m') = date_format(now(), '%m')
于 2013-02-17T16:38:52.777 に答える
0
履歴テーブルを使用すると、主にパフォーマンス上の理由がある場合に利点があります。ただし、一般的に言えば、大量のデータを計画している場合を除き、当月のデータを前月のデータと分離する必要はありません (ほとんどの RDBMS は、パフォーマンスに影響を与えることなく数百万のレコードを簡単にサポートできます)。 プレゼンテーションのためだけにテーブルを分割することはお勧めしません。
履歴テーブルについては、他のことも考慮する必要があります。たとえば、現在のテーブルから履歴テーブルにデータを移動するには、スケジュールされたイベントが必要です。現在のテーブルを変更する場合は、履歴テーブルも変更する必要があります。また、UNION を使用しているため、すべてのデータを照会するのは少し面倒です。
単一のテーブルに適切なテーブル インデックスを作成し、必要に応じて当月のデータを表示する方が簡単なようです。
ただし、パフォーマンスが問題になる場合は、データを履歴テーブルに移動すると有利になる可能性があることに同意します。
于 2013-02-17T16:55:38.817 に答える
0
次に、新しいユーザーは新しいテーブルになりますか?
これ：
- mysql サイト ユーザーに DDL 権限 (CREATE TABLE) を暗示します (手動またはある種の crontab タスクを介して行う場合を除く)
- すべてのユーザーのデータを取得したいとき、または単にユーザーのリストを知りたいときはいつでも、mysql user_schema テーブルと一般的な dml 操作を混在させずに簡単に解析可能にすることはできません。
本当に答えは簡単ではなく、決定的なものではありませんが、理想としては、「宗教的」な意見として、私は自分のウェブサイトの日常生活でモデル操作を避けるようにしています。メタモデル化を目指しましょう。
それが役に立ったことを願って、
S.
于 2013-02-17T16:38:24.007 に答える