16

それで、「ハック」と見なされるかどうかわからないという興味深い質問があります。いくつかの質問に目を通しましたが、重複が見つからなかったので、ここにあります。基本的に、これが信頼できないのか、それとも悪い習慣と見なされるのかを知る必要があります。

一意の自動インクリメント ID と created_at タイムスタンプを持つ非常に単純なテーブルがあります。（問題の概念を明確にするために私の問題を簡略化したもの）

+-----------+--------------------+
| id        |created_at          |
+-----------+--------------------+
| 1         |2012-12-11 20:35:19 |
| 2         |2012-12-12 20:35:19 |
| 3         |2012-12-13 20:35:19 |
| 4         |2012-12-14 20:35:19 |
+-----------+--------------------+

これらの列は両方とも動的に追加されるため、新しい「挿入」は常により大きな ID を持ち、常により大きな日付を持つと言えます。

目的 - 非常に単純に、 created_atによって降順で並べ替えられた結果を取得します。

解決策 1 - 日付の降順で並べ替えるクエリ

SELECT * FROM tablename
ORDER BY created_at DESC

解決策 2 - ID の降順で並べ替えるクエリ

SELECT * FROM tablename
ORDER BY id DESC

解決策 2 は悪い習慣と見なされますか? または、解決策2は物事を行う適切な方法ですか。単に答えを得るだけでなく、概念を理解しようとしているので、あなたの推論の説明は非常に役に立ちます. 前もって感謝します。

4

5 に答える 5

12

典型的な実践では、ほとんどの場合、自動インクリメント ID をソートしてレコードを作成順に (どちらの方向にも) 表示できると想定できます。ただし、これはデータの観点からは移植可能とは見なされないことに注意してください。キーが再作成される別のシステムにデータを移動することもできますが、created_at データは同じです。

実際、この問題についてはかなり良いStackOverflow の議論があります。

基本的な要約は、created_at による順序付けがベスト プラクティスと見なされる最初のソリューションです。ただし、最高のパフォーマンスを得るには、created_at フィールドを適切にインデックス化してください。

于 2012-12-22T19:04:14.747 に答える
8

行を一意に識別する以外の目的でIDに依存しないでください。これは、レコードが作成された順序にのみ対応する任意の番号です。

このテーブルがあるとしましょう

ID  creation_date
1   2010-10-25
2   2010-10-26
3   2012-03-05

この場合、creation_dateではなくIDでの並べ替えが機能します。

将来的には、おっと、レコードID＃2の作成日を2010-09-17に変更する必要があることに気付きました。IDを使用した並べ替えで、レコードが同じ順序で報告されるようになりました。

1   2010-10-25
2   2010-09-17
3   2012-03-05

新しい日付では、次のようになります。

2   2010-09-17
1   2010-10-25
3   2012-03-05

短いバージョン：作成された目的のためにデータ列を使用します。データの副作用に依存しないでください。

于 2012-12-22T19:24:23.687 に答える
6

2 つのオプションにはいくつかの違いがあります。

1 つ目は、異なる結果が得られることです。

の値はcreated_at、サーバーで調整されている時間の影響を受ける可能性がありますが、id列は影響を受けません。時間が後方に (手動または時刻同期ソフトウェアによって自動で) 調整されると、後で挿入されたレコードを取得できますが、タイムスタンプは以前に挿入されたレコードよりも前になります。この場合、注文する列に応じて異なる順序が得られます。どの順序を「正しい」と考えるかは、あなた次第です。

2つ目はパフォーマンスです。クラスター化インデックスの方が高速である可能性がありORDER BYます。

クラスター化インデックスがクエリを高速化する仕組み

行データはインデックス検索が導く同じページにあるため、クラスター化インデックスを介して行にアクセスするのは高速です。

デフォルトでは、クラスター化されたキーは主キーであり、あなたの場合はおそらくid列です。ORDER BY idの方が よりわずかに速いことがわかるでしょうORDER BY created_at。

于 2012-12-22T19:03:37.357 に答える
4

ID順、挿入順順。

バッチプロセスなど、挿入が遅れる可能性があるユースケースがある場合は、created_atで注文して時間で注文する必要があります。

どちらもニーズに合っていれば問題ありません。

于 2012-12-22T19:11:48.760 に答える