none
management studioの「行の編集」を開いたときの表示順を数値順にしたい RRS feed

  • 質問

  • よろしくお願いします。

    SQLServer2012を使用しています。

    とあるテーブルを作成しデータを登録したのですが、management studioの「行の編集」を開いたときに、

    自分の思ったとおりの順番に表示されてくれません。

    具体的には、

    列① 列② 列③ 列④

    80  4   午後 2

    81  5   午前 2

    70  6   午後 2

    60  7   午前 2

    のような形になってしまいます。データ型は、列③はvarchar(16)で、それ以外は全てsmallintです。

    自分で作成していないテーブルで、登録した順ではなく、数値の順番に並び変わってくれるテーブルを見たことがあり、

    このテーブルもそうなってほしいのですが、どのように設定すればよいのでしょうか。

    できればOrder byで列①、列②を指定したときのように並び変わって欲しいのです。

    知識不足のため、正しい表現が出来ていないかもしれないのですが、よろしくお願いします。



    ※タイトルを変更いたしました。
    2017年1月24日 5:21

回答

  • 原因というのが、私の作ったテーブルに主キーがまだ設定されていなくて、その状態だとおそらく登録した順の表示になってしまうようです。

    厳密には主キーではないため補足しておきます。

    大前提としてSurferOnWwwさんが言及されていますように「たまたまそういう結果になっただけで、それが保証されているわけではありません」は変わりません。
    その上で、SQL Serverはデータの格納方法に関する仕様を公開しています。

    クラスター化テーブル、ヒープ、およびインデックスで説明されていますが、ざっくりとクラスター化インデックスが存在すればクラスター化テーブル形式となり、存在しなければヒープ形式で格納されます。
    ここでクラスター化インデックスの条件はUNIQUE制約でかつテーブルに対して1つしか作成できません。つまり、クラスター化インデックスの条件と主キーの条件がほとんど一致するため、一般的には主キー=クラスター化インデックスに指定されます。

    さて、クラスター化インデックス(≒主キー)の存在するクラスター化テーブル形式はクラスター化インデックス順に行が格納されます。そのため、クエリーの際に順序を指定しなかった場合に、クラスター化インデックス(≒主キー)順になりやすいです。

    一方、クラスター化インデックスの存在しないヒープ形式の場合、行追加順に格納されます(ただし、行削除後の行追加でどのような振る舞いをするかは未定)。そのため、行追加順になりやすいです。

    2017年1月24日 9:02
  • SELECT 実行時に ORDER BY を指定しない場合並び順は保証されません。

    「今は登録した順」とのことですが、たまたまそういう結果になっただけで、それが保証されているわけではありません。


    【追伸】

    この話はこのフォーラムでも時々あって、例えば以下のような過去スレッドもあります。ご参考まで。

    ORDER BYを指定しないSELECT文の並び順の保障について
    https://social.msdn.microsoft.com/Forums/ja-JP/68226e85-6298-4246-bc7d-cbc0df58aee8/order-byselect?forum=sqlserverja

    2017年1月24日 5:28
  • ご返信ありがとうございます。

    確認までして頂いてありがとうございます。お手数おかけしてすみません。

    画像までお見せしていただいて、、大変勉強になります。

    また、本当に申し訳ないのですが、勘違いしていた原因が判明致しました。

    初歩的過ぎて恥ずかしいのですが、回答してくださったお二人に申し訳ないので原因を書かせて頂きます。

    原因というのが、私の作ったテーブルに主キーがまだ設定されていなくて、その状態だとおそらく登録した順の表示になってしまうようです。

    そういえばまだ主キーの設定をしていなかったと思い、正しく設定しましたところ、主キーの列の数字順になりました。

    おそらくなのですが、主キーを設定しないでテーブルを使い始める人が基本的にいないので、とんちんかんな質問を

    してしまったのだと思います。

    大変申し訳ございません。次回から、初歩的なことは先に確認するように致します。


    2017年1月24日 8:33

すべての返信

  • SELECT 実行時に ORDER BY を指定しない場合並び順は保証されません。

    「今は登録した順」とのことですが、たまたまそういう結果になっただけで、それが保証されているわけではありません。


    【追伸】

    この話はこのフォーラムでも時々あって、例えば以下のような過去スレッドもあります。ご参考まで。

    ORDER BYを指定しないSELECT文の並び順の保障について
    https://social.msdn.microsoft.com/Forums/ja-JP/68226e85-6298-4246-bc7d-cbc0df58aee8/order-byselect?forum=sqlserverja

    2017年1月24日 5:28
  • ご回答ありがとうございます。

    説明があいまいで申し訳ございません。

    SELECT文を書く際にはORDERBYを指定しなければならない、とのことなのですが、

    management studioの「行の編集」から開いた際にも、何か順序の指定ができるように思えるのですが、いかがでしょうか。

    普段、SELECT文やUPDATE文を書くよりも、management studioのオブジェクトエクスプローラから「行の編集」

    を選んでデータを確認したり変更したりということが多いため、できればこちらの表示順を設定できるようになりたいのです。

    それとも、こちらでもたまたま数字順に見える並びになっているだけなのでしょうか。

    2017年1月24日 6:05
  • >management studioの「行の編集」から開いた際にも、何か順序の指定ができるように思えるのですが、いかがでしょうか。

    行の編集を開く際には、order byは指定されていません。
    指定するのであれば、「行の編集」で表示された結果において右クリックし、ペイン -> SQL と進んでSQLを表示し、そこにorder byを指定して下さい。
    その後、再度「行の編集」で表示された結果において右クリックし、「SQLの実行」をクリックしてください。


    ★良い回答には回答済みマークを付けよう! MVP - .NET  http://d.hatena.ne.jp/trapemiya/

    2017年1月24日 7:22
  • > こちらでもたまたま数字順に見える並びになっているだけなのでしょうか。

    SQL Server 2012 の SSMS は分かりませんが、SQL Server 2008 の SSMS(今自分が使えるのはこれだけ)でデータベースを右クリックして表示されるメニューの[上位 1000 行の選択(W)]、[上位 200 行の編集(E)]と同じならそうです。

    例えば[上位 1000 行の選択(W)]は以下のクエリが発行されます。そこに並び順を指定するものはありません。

    /****** SSMS からの SelectTopNRows コマンドのスクリプト  ******/
    SELECT TOP 1000 [OrderID]
          ,[CustomerID]
          ,[EmployeeID]
          ,[OrderDate]
          ,[RequiredDate]
          ,[ShippedDate]
          ,[ShipVia]
          ,[Freight]
          ,[ShipName]
          ,[ShipAddress]
          ,[ShipCity]
          ,[ShipRegion]
          ,[ShipPostalCode]
          ,[ShipCountry]
      FROM [NORTHWIND].[dbo].[Orders]

    [上位 200 行の編集(E)]の場合も同様で TOP 1000 が TOP 200 に変わるだけです。
    2017年1月24日 7:23
  • 並び順のみの指定であれば[ペイン(N)]⇒[抽出条件(C)]とした方が簡単なようです。SQL Server 2008 の SSMS ですが、以下の画像を見てください。

    ちなみに、[上位 200 行の編集(E)]の 200 を変えることも可能です。上の画像の右側のウィンドウで赤枠で囲った「式  1000」で 200 を 1000 に変更しています。

    2017年1月24日 7:49
  • ご返信ありがとうございます。

    確認までして頂いてありがとうございます。お手数おかけしてすみません。

    画像までお見せしていただいて、、大変勉強になります。

    また、本当に申し訳ないのですが、勘違いしていた原因が判明致しました。

    初歩的過ぎて恥ずかしいのですが、回答してくださったお二人に申し訳ないので原因を書かせて頂きます。

    原因というのが、私の作ったテーブルに主キーがまだ設定されていなくて、その状態だとおそらく登録した順の表示になってしまうようです。

    そういえばまだ主キーの設定をしていなかったと思い、正しく設定しましたところ、主キーの列の数字順になりました。

    おそらくなのですが、主キーを設定しないでテーブルを使い始める人が基本的にいないので、とんちんかんな質問を

    してしまったのだと思います。

    大変申し訳ございません。次回から、初歩的なことは先に確認するように致します。


    2017年1月24日 8:33
  • 「どうやらプライマリキーが数値型の場合はプライマリキーの昇順で帰ってくることが事が多いみたい」
    とは私も感じていました。
    しかしそれには何の根拠も保証もありませんし、そんな仕様は聞いたことがありませんので、そんなこともある程度にとらえてください。
    2017年1月24日 8:54
  • 原因というのが、私の作ったテーブルに主キーがまだ設定されていなくて、その状態だとおそらく登録した順の表示になってしまうようです。

    厳密には主キーではないため補足しておきます。

    大前提としてSurferOnWwwさんが言及されていますように「たまたまそういう結果になっただけで、それが保証されているわけではありません」は変わりません。
    その上で、SQL Serverはデータの格納方法に関する仕様を公開しています。

    クラスター化テーブル、ヒープ、およびインデックスで説明されていますが、ざっくりとクラスター化インデックスが存在すればクラスター化テーブル形式となり、存在しなければヒープ形式で格納されます。
    ここでクラスター化インデックスの条件はUNIQUE制約でかつテーブルに対して1つしか作成できません。つまり、クラスター化インデックスの条件と主キーの条件がほとんど一致するため、一般的には主キー=クラスター化インデックスに指定されます。

    さて、クラスター化インデックス(≒主キー)の存在するクラスター化テーブル形式はクラスター化インデックス順に行が格納されます。そのため、クエリーの際に順序を指定しなかった場合に、クラスター化インデックス(≒主キー)順になりやすいです。

    一方、クラスター化インデックスの存在しないヒープ形式の場合、行追加順に格納されます(ただし、行削除後の行追加でどのような振る舞いをするかは未定)。そのため、行追加順になりやすいです。

    2017年1月24日 9:02
  • 主キーの設定が有ろうが無かろうが SELECT 実行時に ORDER BY を指定しない場合並び順は保証されないということに変わりないということは理解されているでしょうか?

    先のレスで書いたように、SSMS の[上位 1000 行の選択(W)]および[上位 200 行の編集(E)]の SELECT クエリには ORDER BY は指定されていません。

    なので、SSMS での表示結果が、

    > 原因というのが、私の作ったテーブルに主キーがまだ設定されていなくて、
    > その状態だとおそらく登録した順の表示になってしまうようです。

    > 正しく設定しましたところ、主キーの列の数字順になりました。

    ・・・となったというのも保障された結果としてそうなったわけではないことは理解されているでしょうか?

    質問者さんが SSMS 上で見るだけの話だから、たまたまでも保証されてなくても何でいいから望む結果が得られれば良いということなのかもしれませんが。


    #でも、「たまたま」の話をこういうフォーラムですると言うのはちょっと違うと思うのですが・・・

    2017年1月24日 9:11
  • 散々書かれていますが、順序を指定しない場合、並び順は不定です。Oracleも含めて検索すると、「ある日から登録順に取り出せなくなった」という質問があったはず。「データの集合を扱っているので、そこには順番なんてない」と、ベン図で説明してあったのが妙に納得いったのを覚えている。

    Jitta@わんくま同盟

    2017年1月24日 11:40