4

私は mysql が初めてで、最初の php-mysql アプリケーションをコーディングしました。

ユーザーが自分のアカウントに好みのデバイスを追加できるようにする 30 個のデバイス リストがあります。

そこで、このような特定のユーザーIDの下にいくつかのデバイスIDが保存されているmysqlテーブル「A」を作成しました

UserID  |  Device Id

1       |  33
1       |  21
1       |  52
2       |  12
2       |  45
3       |  22
3       |  08
1       |  5 
more.....

たとえば、5000 のユーザー ID と 30 のデバイス ID があるとします。

& 各ユーザーのアカウント レコードに (平均で) 15 個のデバイス ID がある場合。

次に、テーブル「A」の下にある 5000 X 15 = 75000 レコードになります。

それで、私の質問は、mysql テーブルに保存できるレコードの数に制限はありますか?

上記のようにレコードを保存するための私のアプローチは正しいですか?? さらにユーザーを追加すると、クエリのパフォーマンスに影響するかどうか。

またはそれを行うためのより良い方法はありますか?

4

2 に答える 2

3

整数のみの 2 つの列を持つ MySQL テーブルの制限に近づく可能性はほとんどありません。

クエリのパフォーマンスが本当に気になる場合は、先に進んで両方の列にインデックスを投げることができます。デバイス ID のインデックスを使用しても、テーブルの挿入/更新のコストは無視できる可能性があります。データベースが巨大になると、「どのユーザーがこのデバイスを好むか」などのクエリを高速化できます。「このユーザーが好むデバイス」を尋ねるクエリも、ユーザーのインデックスを使用すると高速になります。

このテーブルを、2 つの部分からなる複合キー (インデックス付き) を持つ単純な 2 列のテーブルにすることをお勧めします。このようにして、それは可能な限りアトミックになり、一部の人が「パフォーマンスを向上させる」ために提案する可能性のある愚かなことは必要ありません。

アトミックで通常の状態に保ちます。パフォーマンスは良好で、DBMS の制限を超えることはありません。

于 2013-02-16T07:17:30.570 に答える
1

何も問題はありません。サーバーのスペースを節約したい場合は、心配する必要はありません。データベースに基礎となる仕事をさせてください。.を使用して、データベースに適切にインデックスを付けますID - int(10) primary auto increment。必要に応じてスケーラビリティについて考えてください。最初の目標は、作成中のアプリケーションを完成させることです。次に、テストします。それがラグや問題を引き起こしていることがわかった場合は、問題を解決するために心配を始めてください. おそらく直面することさえないかもしれないことに悩まないでください。

ただし、アプリケーションの規模 (75k から 1 lac レコード) を考慮すると、それほど大きな作業ではないはずです。あるいは、ユーザーのためにこのようなスキーマを持つことができます

(デバイステーブル)

device_id
23
45
56

user_id |  device_id
1       |  23,45,67,45,23
2       |  45,67,23,45

つまり、device_ids を配列に格納し、特定のユーザーの device_id を次のように取得します。

$device_for_user=explode(',',$device_id)

もちろん、device_id は mysql データベースから取得されます。だからあなたは持っているでしょう

$device_for_user[0]=23
$device_for_user[1]=45

アムドなど。

しかし、この方法はあまり良い設計やアプローチではありません。ただし、参考までに、これはそれを行う1つの方法です

于 2013-02-16T07:10:39.747 に答える