MySQLのauto_incrementingインデックスからの変更

Question

ユーザがノートを作成し、カラム（auto_incrementingフィールド）を持つデータベースに同期させるノートアプリケーションがあります。問題は、ユーザーがインターネットに接続していないときには作成しないので少し複雑になるため、一時的にnoteIdを割り当てて、メモシステム構造の階層に関連する他のものを入れなければならないということです。

私はauto_incrementオプションを一斉に削除し、ローカルデバイス（iPhone/iPad - Objective C）にnoteIdとしてデータベースで使用できる一意のID（タイムスタンプ）を作成することを考えています。この方法で、ユーザーがオフラインで、後で再接続すると、一意のIDを送信するのと同じくらい簡単に同期できます。

つの質問：

1. どのようにこれがパフォーマンスに影響を与えるのでしょうか？データベースに500,000の音符があり、ユーザーがその音符の1つに変更を加えたとしましょう。 auto_incrementingフィールドでは、システムが256000のnoteIdを見つけるのが簡単だと思いますが、一般的なnoteIdシステムでは、88689034のnoteIdを見つけるのはずっと長いプロセスでしょうか？
2. ユーザのデバイス上でメモの一意のIDをローカルに生成するにはどうすればよいでしょうか？タイムスタンプ？

Answer 1

一意のIDを生成する最も一般的な方法の1つは、UUID/GUIDを使用することです。 MySQLにはUUID関数があり、.NETにはGUID関数があり、PHPやJavaScriptで関数を作成するのは簡単です...クライアントアプリケーションの言語を指定しないでください;）しかし、確かに可能ですパフォーマンスに影響します。 UUIDのパフォーマンスを向上させる最善の方法は、16進文字列を2進数に変換し、複数のINT列に格納することです。

EDIT：ちょうど良いアイデアを考えた...なぜあなたはデバイスでIDを生成する必要がありますか？ノートを作成して、デバイスが接続しているときにノートをサーバに送信し、その時点でサーバにIDを生成させることはできませんか？おそらく、デバイス上では、デバイスの一時IDを生成してそれを追跡するでしょうが、実際のIDは引き続きサーバーによって生成されます。

Answer 2

notesあなたはLotus Notesですか？または、他の何か？何か他のものがあれば、何？

これは、uuidsが対処することを意図したものです。タイムスタンプは非常に小さいクライアントベースであっても適切です。または、クライアント識別子とをローカルに生成された自動インクリメント値を主キーとして使用します。

はい、キーが大きいほど、クエリが遅くなりますが、その差は比較的小さいです。

Answer 3

バックエンドのパフォーマンスは、特にテーブルが正しく設計されている場合、特にDBのNoteIDフィールドが正しくインデックスされている場合、アプリケーションのパフォーマンスに影響を受けてはなりません。また、バックエンドデータベースシステムで500,000レコードを索引付けすることは不合理ではありません。しかし、それはDBがインデックスなどを更新するために定期的なメンテナンスを必要としないことを意味しません。

ユーザがオフラインでノートを作成することができれば、データベースのNoteIDフィールドのキーとしてuuidsをローカルに作成することは意味があります。 how-to-create-a-guid-uuid-using-the-iphone-sdk

パフォーマンスに関しては、UUIDは32文字のサイズ範囲にあります。これはおそらくノートの1行に満たないテキストにすぎません。したがって、Uuidをローカルにメモとともに保存し、ノートと共にDBに送信することでパフォーマンスの問題が最小限に抑えられます。

Answer 4

私はUUIDがうまくいくと思います。悪い解決策ではありません。

しかし、ここではクライアントが生成したIDを使用してクライアント情報を信頼することはないというセキュリティ上の配慮があります。

ユーザーが自分のメモにのみ影響を与えることができ、認証されたセッションに結び付けられ、単に自分のUUIDを推測して他のユーザーのメモに影響を与えない場合、

たとえば、メモレコードにもuser_idフィールドがあり、ユーザーが自分のメモを読み込み、挿入、または更新できるようにするだけであれば、あなたはうまくいきます。

パフォーマンスが向上する限り、キーフィールドの長さはパフォーマンスに影響し、INT（4バイト）およびCHARまたはVARCHAR（32）フィールドから大きく飛びます。あなたのインデックスは、さらに多くのメモリ/ストレージを使用します。あなたは、変化が目立つかどうかを確認するためにテストする必要があります。

スケーラビリティを念頭に置いて、私はむしろクライアントのCPUサイクルを自分で使いたいのですが、使用する方法は現在の方法と同じです。

メモを複数の場所（ブラウザ、アプリケーションなど）から更新できる場合は、このタイプの問題を究極的に解決したい場合は、複雑さを犠牲にして調査してくださいversion vectors。