Database

インラインユーザー定義関数

nakaP — Thu, 03 Sep 2009 15:34:00 GMT

SQLServerでは、テーブル型を返すユーザー定義関数をインラインユーザー定義関数と呼ぶそうです。

例えば、以下のようなテーブルを作り、データを格納します。

(環境：SQL Server 2005 Express Edition)

[テーブル]
member_table
member_code int
member_name nvarchar(50)
[データ]
member_code member_name
1           中博俊
2           じゃんぬねっと
3           nakaP

member_codeを指定して、該当する行を返すユーザー定義関数を作ります。

CREATE FUNCTION dbo.Test(@code INT)
RETURNS TABLE
AS RETURN (SELECT * FROM member_table WHERE member_code = @code)
GO

そしてユーザー定義関数を実行すると、以下のような結果が返ります。

SELECT * FROM Test(1)
[結果]
member_code member_name
1           中博俊

ここでテーブルに列を追加し、データを編集します。

[テーブル]member_table
member_code  int
memver_class nvarchar(50)
member_name  nvarchar(50)
[データ]
member_code member_class member_name
1           代表         中博俊
2           代表         じゃんぬねっと
3           下っ端       nakaP

そして再度ユーザー定義関数を実行すると、以下のような結果に変わります。

SELECT * FROM Test(1)
[結果]
member_code member_name
1           代表

列名と内容が一致していません。なぜでしょうか。

まず、sys.objectsのid列を利用して、sys.columnsの情報を取得します。

(SQL Server 2000 ではsysobjects、syscolumns)

それぞれの詳細は以下をご覧ください。

sys.objects

sys.columns

なお参考にsys.parametersもご覧になられるといいかもしれません。

(SQL Server 2000 ではsysparameters)

sys.parameters

SELECT * FROM sys.columns WHERE object_id = (SELECT object_id FROM sys.objects WHERE name = 'Test')
object_id name column_id ･･･
*******   id   1
*******   name 2

項目数は多いですが、member_code列とmember_name列が返されることが分かります。

ここでも列名と内容が一致していません。

次にsp_sproc_columnsの情報を見てみます。

sp_sproc_columns

EXEC sp_sproc_column @procedure_name = 'Test'

この結果のTYPE_NAME列を見ると、「table」となっています。

以上の結果より、インラインユーザー定義関数はテーブルを返しますが、戻り値の列数は２つしかないことが分かります。

つまり、テーブル定義の変更後は、３列の結果を２列のテーブルとして返しているのです。

そして、戻り値の列名は便宜上の列名であり、必ずしも元テーブルの列名と同期が取られているわけではないようです。

この問題を解決するには、

１．インラインユーザー定義関数で個別に列名を指定しておく

２．sp_refreshsqlmoduleを実行する

ことになります。

これがバグなのか仕様なのかは分かりませんが、知っていないとハマりそうですね。

「select * は便利だけど便利じゃないよ」

ってことですね。

SQL Server 2008 Express 3つの種類

nakaP — Fri, 12 Jun 2009 16:46:00 GMT

ネタ元：おぎわらさんとこ

「SQL Server 2008 Expressに3つの種類がある」って書かれてたので、気になって調べてみました。

・Microsoft SQL Server 2008 Express

・Microsoft SQL Server 2008 Express with Tools

・Microsoft SQL Server 2008 Express with Advanced Services

with Tools、with Advancedに付いているグラフィカル管理ツールはSQL Server 2008 Management Studio Basicという名前だそうで。

with AdvancedにはさらにReporting Servicesが付いてるみたいです。

どんどんリッチな環境になってきてるのでうれしいかもｗ

テーブルの主キー

nakaP — Fri, 01 May 2009 00:35:00 GMT

テーブルにはほぼ主キー(Primary Key)が設定されていると思うのですが。

column_1  Key_1
column_2  Key_2
column_3
column_4
・
・
・

こんな風に先頭の列からキーになってるのは特に問題ないのですが、

column_1
column_2  Key_2
column_3
column_4  Key_1
・
・
・

みたいに途中の列にキーが設定されているとものすっっっごく違和感を感じます。

これってCOBOLerの感覚・・・なのかな・・・？

SQL Server 2005 Express Editionの容量制限

nakaP — Wed, 06 Aug 2008 11:36:00 GMT

・[Hello Another World!]SQL Server 2005 Express Edition : データベースの容量が 4GB に制限される

・[Hello Another World!]SQL Server 2005 Express Edition でデータベースの容量が4GBを超えたときの挙動

・[Hello Another World!]SQL Server 2005 Express Edition : データベースの容量が 4GB に制限されるその2

ueさんとこ。ちょっと必要になるかもしれないのでメモ。

現在のところは、

・データベース毎の容量の制限が 4GB である

・データベースとはPRIMARYファイルグループのことを指す

という認識です。

これは・・・

・「HANBAI」と「KAIKEI」というデータベースがあった場合、それぞれが 4GB まで容量を増やすことが出来る？

・PRIMARYじゃないファイルグループを追加すれば 4GB を超えられる？

ということなのかな？

むー。その他の機能制限が気にならないなら、業務でExpress Editionという選択も有りなのかも。

SQLServer 2008 日本語版出荷開始

nakaP — Sat, 02 Aug 2008 08:17:00 GMT

http://www.microsoft.com/japan/sqlserver/2008/default.mspx

SQLServer2008日本語版の提供が８／１より開始されたそうです。

#我が社もそろそろ導入・・・か？

テーブルのキー設定

nakaP — Tue, 01 Jul 2008 01:01:00 GMT

ネタ元：http://bbs.wankuma.com/index.cgi?mode=al2&namber=21230

#多分思いっきり勘違いしていたわけですが(^^;

例えば発注システムを作ろうとした場合、以下のようなテーブルを持つ必要があります。
(簡易すぎると思いますが)

・取引先マスタ・・・取引先コード、名称、・・・
・商品マスタ　・・・商品コード、商品名、単価、・・・
・発注データ　・・・伝票番号、取引先コード、商品コード、単価、数量、・・・

各マスタに関しては、コード自体の変更が起こったり、マスタの変更履歴を取りたいという要望がある可能性があるので、サロゲートキーを用意するという人が多いと思います。
また、発注データに関しても、変更履歴を残すなどの理由でサロゲートキーを用意することがあります。
この辺は、履歴も同一テーブル内で保持していたほうが便利な場面が多いと思いますので、サロゲートキーは有効だと思います。

この場合、発注データと各マスタの紐づけはＩＤで行うようになります。

・取引先マスタ・・・ＩＤ、取引先コード、名称、・・・
・商品マスタ　・・・ＩＤ、商品コード、商品名、単価、・・・
・発注データ　・・・ＩＤ、伝票番号、取引先ＩＤ、商品ＩＤ、単価、数量、・・・

ここで、商品に対して単価が１：１であれば楽なのですが、そういう場面はほとんどないでしょう。
同じ商品に対して複数の取引先があり、取引先ごとに単価も違ってくると思います。
そうした場合、取引先・商品別の単価を持つ必要がでてきます。

・取引先別商品別単価テーブル・・・取引先ＩＤ、商品ＩＤ、単価・・・

この場合、取引先ＩＤと商品ＩＤの２つでユニークなレコードとなります。
この「取引先別商品別単価テーブル」にサロゲートキー（ネタ元でいう人口キー）が必要なのかということだと思ったのですが・・・。

結論としては、僕は「要らない」と判断します。
このテーブルの場合だと、伝票を作成する際に単価を取得するだけです。
単価という項目は、発注データの中にも保持されます。
そして、単価が変更されたからと言って、過去の発注データ内の単価まで影響を及ぼすことはありません。
その時点で設定されている単価を保有していれば良いだけなのです。
履歴も保持したい、という要望もあるかもしれませんが、同一テーブルに保持する必要もないしメリットも感じませんので、トリガなどを使用して別テーブルに保存していけばよいと思います。

すべての場合で、とは言いませんが、このような場合だと複合キーであってもよいと思います。
なので、今のところの僕のスタンスは以下のとおり。

・ナチュラルキーよりはサロゲートキーを使う
・履歴の必要性が低ければサロゲートキーは必要なし、トリガで別テーブルに保存する
・サロゲートキー同士の複合キーなら有り