今日、OSADAへ行ったら、シャア専用ジーンズなるものが・・。
種類は、青いノーマルなジーンズと、真っ赤なジーンズ(笑
(一応、両方ともシャア専用ジーンズになっていた)
正直、デザインめちゃくちゃダサい！！
でも、安かったらネタとして買ってみようかなと思ったけど。
・・・。
・・・・・。
・・・・・・・。
・・・・・・・・・。
・・・・・・・・・ご、50,000円！？
ちょっと、いくらなんでも高すぎる・・・よね。
・・リリースしました。
今日も本を読みつつ、自分自身がよく理解できていない部分を調べることに。
「COMPUTE句とCOMPUTE BY句は使わない」
これは自分の読んでいる、SQLServerの書籍に載っていた言葉。
使わないなら、載せなきゃいいのに・・・というのは素人考えだろうか。
ただ、COMPUTE句のことも良く知らなかったし
使わない理由が今ひとつ納得いかなかったので、ヘルプで調べてみることに。
どうやらSQLServer2000では、「COMPUTE句」と「COMPUTE BY句」は
過去との互換性を保つために用意されているらしい。
あと、ANSI 標準ではないから、使うべきではないとの記述も。
(これは書籍にも書いてあった)
(？)ちなみにCOMPUTE句とは。
これは、SELECT文の中で使用する。
COMPUTE句を書く位置は、ORDER BY句の下。
COMPUTE句、またはCOMPUTE BY句を使うと
結果セットが複数に分かれる。
例えば、以下のようなSQL文の場合．．．。
(Northwindデータベースを使用)
－－－－－－－－－－－－－－－－－－－－
Select * FROM [Order Details]
ORDER BY ProductID
COMPUTE SUM(UnitPrice) , SUM(Quantity)
－－－－－－－－－－－－－－－－－－－－
2つの結果セットが返される。
1つ目の結果セットには、通常の抽出結果が。
2つ目の結果セットには、UnitPriceおよびQuantityの合計値が表示される。
このように通常の結果と、小計の結果が返ってくるのがCOMPUTE句の特徴だ。
小計を返すことから、COMPUTE句には、以下の集計関数しか利用することができない。
ちなみに使用可能な集計関数は、以下のとおり。
AVG | COUNT | MAX | MIN | STDEV | STDEVP | VAR | VARP | SUM
ちなみに、COMPUTE BY句は・・。
－－－－－－－－－－－－－－－－－－－－
Select * FROM [Order Details]
ORDER BY ProductID
COMPUTE SUM(UnitPrice) , SUM(Quantity) BY ProductID
－－－－－－－－－－－－－－－－－－－－
小計列を指定した後で、「BY 列名」の形で指定を行う。
COMPUTE BY句を使うと、「BY 列名」で指定した
列名のグループごと結果セットが分かれる形になる。
上記の例で言うと、以下のような形で結果セットがわかれる。
1つ目の結果セット：ProductIDが「1」のデータ抽出結果
2つ目の結果セット：ProductIDが「1」の小計(この場合、UnitPriceとQuantity)を表示。
3つ目の結果セット：ProductIDが「2」のデータ抽出結果
4つ目の結果セット：ProductIDが「2」の小計
以下、同じようにProductIDごとグループ化された形で出力される。
※ちなみに、COMPUTE またはCOMPUTE BY 句に、ntext、text、image 型を指定することはできない。
「使わないでくれ」という関数を詳細にまとめなくても良いだろうが、一応覚え書きということで・・。
今回のCOMPUTE句、COMPUTE BY句に代わる、関数もあるようなので後日紹介したいと思う。
今宵もTransact-SQLについて。
「WITH TIES句」とは？
勉強中に気になったので調べてみることにした。
どうやらSELECT文の中で使うらしい！
(全然気づかなかった！！ マイナーな機能だと思う．．)
●WITH TIES句とは
・ORDER BY のキー列の値が TOP n (PERCENT) の最終行と同じ値を持つ行を
基の結果セットから追加行として返す。
※ORDER BY句を使用している時のみ、指定可能。
という機能のようだ。(T-SQLのヘルプより抜粋)
読んだだけだと、よくわからない・・・(；_；
試してみることにした。
●テーブル名：Orders(キーは受注番号)
| 受注番号 | 得意先コード | 得意先名 |
| 0001 | 10 | A商店 |
| 0002 | 15 | B商店 |
| 0003 | 20 | C商店 |
| 0004 | 10 | A商店 |
| 0005 | 25 | D商店 |
| 0006 | 10 | A商店 |
上記のようなデータが入っているテーブルを参考に考えてみたい。
↓まずは、WITH TIES句を使わないSELECT文
－－－－－－－－－－－－－－
SELECT TOP 1 * FROM Orders
ORDER BY 得意先コード
－－－－－－－－－－－－－－
[TOP 1]を指定しているので、一番得意先コードの若い「A商店」の
受注番号：0001のデータのみ表示される。
↓WITH TIES句を使うと．．．
－－－－－－－－－－－－－－
SELECT TOP 1 WITH TIES *
FROM Orders
ORDER BY 得意先コード
－－－－－－－－－－－－－－
| 受注番号 | 得意先コード | 得意先名 |
| 0001 | 10 | A商店 |
| 0004 | 10 | A商店 |
| 0006 | 10 | A商店 |
[TOP 1]を指定しているが、A商店のデータが全て抽出されるのだ。
ORDER BY句で指定した列で、グループ化をしているようなイメージだろうか。
ちなみに、この例で言うと、[TOP 2]や[TOP 3]を指定した場合も結果は同じとなる。
[TOP 4]を指定すると、「A商店の3件」＋「B商店」のデータが抽出される。
しかし、今まで使っていなかった機能だけに、実務でどのような使い道があるか全く思い浮かばない・・。
ゆくゆくは、有効な使い道というのも指南できれば良いと思うが、少なくとも数年はかかりそうな・・。
text型の列をWhere条件に使いたい場合。
-------------------------------------------------------
例）Select * FROM テーブル名
Where
Len(Convert(varchar(●●), 列名)) > 500
※●●には任意の数字が入る。
varcharの場合、1～8000までの数字を指定可能。(SQLServer2000の場合)
-------------------------------------------------------
上記の例だと、文字列の長さが500文字を超える行のみを抽出することができる。
今日text型のデータを抽出する必要があったのだが、「text型のデータは抽出できない！」と思い込んでしまい、自分で解決できなかった＾＾；
(先輩に教えてもらって解決！)
よくよく考えると、型さえ変換すれば普通に抽出できるよなぁと感心。
盲点だった・・。
文字列型についての小ネタ。
MCPについて勉強していたら、こんなことが書いてあった。
データ型割り当てのガイドラインとして、文字列が8,000バイト以下ならvarchar型。
8,000バイトより大きい場合はtext型やimage型を使用と書いてある。
varcharの最大サイズは確かに8,000バイト。
でも、テーブルの列数が多いときには？ よく考える必要があると思う。
例えば、極端だが以下のテーブルを作成したとする。
1列目には、char型8000バイトの文字列。(列名：NAME1)
2列目には、varchar型8000バイトの文字列。(列名：NAME2)
・char型は固定長のため、あらかじめ8000バイト分確保している。
・varchar型は入力した文字数分だけ領域を確保している。
そこで、こんなデータを入れてみる。
NAME2に、50バイト分のデータを入れてみると、上記のエラーメッセージが出力される。
メッセージが示すように、SQLServer(2000)では、1行の最大サイズが8060バイトと決まっている。
(ただし、text型やimage型は含まない)
入力したデータが最大サイズを超えてしまったため、エラーが発生してしまうのだ。
通常、データベースのテーブルは、複数のフィールドを組み合わせて構成される。
そのため、8,000バイト以下とはいえ、安易にvarchar型を使用してしまうことには注意を払いたい。
大量の文字列を格納するテーブルを作る際は、1行の合計サイズがどの程度になるかを予測した上で、
型を決めることをお勧めしたい。(自分自身気をつけたいと思う)
予断だが、1行の最大サイズが8,060バイトなので、NAME2に61バイト分のデータを入れれば
エラーになると思ったのだが、予想に反して50バイト分のデータでエラーになってしまった。
ちょっと調べたが、理由はわからなかった。
多少、余裕をもった設計にしておいた方が良いのかもしれない．．．。
何とかSQL Server Management Stadioをインストールすることが出来た(ホッ)
といっても、大したことをしたわけでなく、雑誌に付属しているDVDを使ってインストールしただけなのだが。
（ SQL Server2005 Developer Edition CTP(JUNE) ）
何にしてもインストールできて良かった。
早速使ってみたのだが、使ってみたらみたで問題発生・・。
AdventureWorks(サンプルデータベース)のテーブルの中身を
Management Studioから開こうとしても、エラーが発生して見れないのだ。
●操作
テーブルを選択 → 右クリック → 「テーブルを開く」
「オブジェクト参照がオブジェクトインスタンスに設定されていません」
また、これはテーブルの参照時だけでなく、新規テーブルを作成しようとした時も発生している。
(新規データベースでデータベースを作成し、新規テーブルを作成しようとしても駄目だった)
ちなみに、SQL文でSELECTすれば問題なく中身を参照できるのだが
ちょっと気になったので、メモとして載せておくことに。
(正規リリースでは問題なく利用できるだろうか・・・。あるいは自分自身で解決できる問題かもしれないが、解決方法を見つけられず。)
●エラー発生環境
・SQL Server2005 Developer Edition CTP(JUNE)
・WindowsXP SP2
先日のマイクロソフトカンファレンスで、「SQL Server 2005ではじめよう」という書籍が発売されるのを知り
Amazonで購入したが、まさかここまで初心者向けな内容とは・・。
ちょっと期待していただけに、肩透かしをくらってしまった。
とはいえ、初めてデータベース扱う人については良いと思う。
説明に関しては、わかりやすかったし、ためになった情報もそれなりにあった。
ただ、雑誌やWEBなどで多少勉強している人は、さして参考になる部分は無い気がする。
もっと実務向けの本を読みたいところだが、書籍の発売はもう少し先の話だろうか。
早めにManagement Studioの日本語版と、日本語のヘルプを手に入れて勉強したい。
もうすぐSQLServer2005の日本語版も提供。
自分も早めに触ってみたいので、インストールしようと試みたが・・。
SQLServer2005のDeveloperEditionのCTP(September)がインストール出来ず。
パッケージ解凍後にエラー発生。
↓エラーメッセージ
Cドライブの空き容量は、約16GBなのだが。
これだけだと、どこに原因があるのかわからないな。
(OSはWINXP SP2)
Management Studioの日本語版だけ入れたかったけど、ひとまず保留。
とりあえず、SQLServer2005 ExpressEdition と
SQLServer Management Studio Express(英語) で
何とかやってみようかと思う。
今日からブログを始めました。
第1回目は、「なぜSQL Serverを深く学びたいと思ったか」の、きっかけを書きたいと思います。
一言で言えば、「プログラムの処理が遅い」とお客様から言われたことがきっかけとなります。
大規模なシステムを担当したことはありませんが、それでも時間の経過につれ
少しずつ処理に時間がかかってしまうことが、よくあります。
中には、処理がタイムアウトになってしまい、先に進むことができないといった事態にまで発展することがあります。
そんな時、よく解決の方法として使うのが、テーブルのインデックス機能でした。
SQLServerにおいて、効果的なインデックスの付け方を勉強していく内に、もっと深くまで勉強してみたいと思ったのが簡単な理由です。
数ある製品の中でSQLServerを選んだ理由は、「単に会社で普段使用している」という理由が一番ですが。
もう一つ、自分の気持ちがSQLServerに大きく傾いた、きっかけとなる出来事がありました。
それは、また別の機会に。