私はロギングデータベースを開発中です。この場合に記録されるコンポーネントのIDは、データベース自体ではなく、レポートを送信するシステムによって決定されます。システムIDは一意のvarcharであり、コンポーネントのIDはシステムによって(遠くの場所で)決定されるため、コンポーネントの主キーがsystem_id + component_idの場合に一意性が保証されます。varcharと複合主キーはmysqlにありますか?
私はこのアプローチが効率的になると思っています。私は自動増分された整数をIDとして使用することができますが、これは、システムが提供する既知の文字列IDを使用する代わりに、生成されたIDを取得できるように、挿入する前に選択操作を行う必要があることを意味します。
データベースは小規模で、わずか数十のコンポーネントで構成されていますが、数千のコンポーネントがあり、数千ものコンポーネントの更新(別のテーブル)があります。古いアップデートは定期的にファイルにダンプされ、データベースから削除されるため、 "大きく"なることはありません。
どのような勧告ですか?
私はいくつかのテストを行いました。データベースは、数十万のコンポーネントとcomponent_updateの行(ランダムに生成された)でうまく動作します。それは各テーブルの1万行ごとに約1メガバイトを測定しました。これは、より多くの結合を実行し、要求ごとに選択するという仕事を節約します。私はIDのサイズを32文字と64文字に制限しましたが、オブジェクト名は通常16文字以下です。 – elite5472