SQL的（集合的）考え方と、ループ（手続き型）の考え方３ - SQLer 生島勘富 のブログ
問題を少し変更 問題）部品在庫から、作成可能な製品の情報をとる。 ※本来はマスタテーブルと組み合わすべきですが、ツールの関係上2テーブルしか同時に表示出来ないので名称で結合する形になります。 SQLで考えるなら という風に考えます。 言い換える 『在庫数が必要量を満みたす製品のみ』 → 『在庫数が必要量を満たさないレコードがある製品を削る』 『満たさない』＝ NOT EXISTS（あるいは、NOT IN） 答えは SELECT * -- 本当は必要なもののみ FROM 部品表 AS bh INNER JOIN 在庫 AS zk ON bh.材料名 = zk.材料名 WHERE NOT EXISTS (SELECT * FROM 部品表 AS bh_s INNER JOIN 在庫 AS zk_s ON bh_s.材料名 = zk_s.材料名 WHERE bh_s.製品名 = bh.製品名 -
SQL的（集合的）考え方と、ループ（手続き型）の考え方２ - SQLer 生島勘富 のブログ
もう一度問題 問題）部品在庫から、作成可能な製品名をとる。 ※本来はマスタテーブルと組み合わすべきですが、ツールの関係上2テーブルしか同時に表示出来ないので名称で結合する形になります。 SQLで考えるなら 答えは SELECT 製品名 FROM 部品表 INNER JOIN 在庫 ON 部品表.材料名 = 在庫.材料名 GROUP BY 製品名 HAVING MIN(在庫.数量 - 部品表.必要量) >= 0; 三枚の図になっていますが、考え方さえ理解していれば数十秒で答えまでたどり着けます。パターン認識じゃないので忘れてもどってことはないのです。 考え方としてはこんな感じになります。 必要なテーブルを引っ付け、ゴールを目指して削り出して行けば良い。 プラモデルと、彫刻の違いです。 言い換えは、他の言語より重要？ プログラムも翻訳と同じですから、言い換えは必要です。 上の図の「SQL的思考
トリガーを自動生成２ - SQLer 生島勘富 のブログ
前回の続き。 非正規化した項目の整合性を維持するトリガーをかいてみます。 トランザクションテーブルにトリガーを設定する。 例として、以下の様な受注明細があったとして、その非正規化項目の整合性を維持するトリガーを書いてみます。 CREATE TABLE T010_受注明細 ( ID int IDENTITY(1, 1) NOT NULL, T000_ID int NOT NULL, 受注CD nchar(10) NOT NULL, 行番号 int NOT NULL, M000_ID int, 製品CD nvarchar(20) NOT NULL, 製品区分 nvarchar(10) NOT NULL, 製品基準日 datetime NO
サロゲートキーは後付けでもできる。 - SQLer 生島勘富 のブログ
業務システムのほとんどはナチュラルキーで構築されていると思います。 しかし、シノニムやトリガーを利用すれば、既存システムを変更することなくサロゲートキーを追加して、それ以降、サロゲートキーによる運用も可能になります。手順は以下の通りです。 元のテーブル 以下の３つのテーブルをサロゲートキーによる運用に変更します。 ■ Foods 料理マスタ 物理名論理名備考 CD料理CD主キー Name名前 Price価格 …… ■ Ingredients 材料マスタ 物理名論理名備考 CD材料CD主キー Name名前 Cost_Price材料費 …… ■ Recipes レシピマスタ 物理名論理名備考 Food_CD料理CD主キー（複合） Ingredient_CD材料CD主キー（複合） Quantity使用量 …… IDカラムを付加する。 現在のテーブル名にIDを採番したシノニムを作成し、全部のテーブ
RDBMSをタバコ屋さんで説明 - SQLer 生島勘富 のブログ
勉強会に参加さてもらい、次の勉強会でお話しすることになったので宣伝です。 前の勉強会では以下の様な実験が話題になっていました。 http://www.doaplus.com/html/bun/bun03_20051101.html まあ、極めて当たり前の結果です。 5000万件が500万件になるというのは、データを横に非正規化すると明細テーブルが要らなくなるから件数が少なくてすむという意味らしい（爆笑）。 非正規化したテーブルに、更に足りない情報をJOINして得ようとすると、効率的なSQLを書くことが困難になって、非常に実行速度が遅くなる。 この結果から「なんでこの項目を非正規化しておかなかったんだ！」っていう連中が出て、テーブル構造はどんどんCOBOLのファイルレイアウトに近づいて行く。 要するに、JOINしたら遅くなると感じるのはテーブル構造が間違っているためですが、その間違った構造を
JOIN禁止と固定長カラムについて - SQLer 生島勘富 のブログ
あまりに気になったので「山本大＠クロノスの日記」にチャチャを入れてみる。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 まあ、政治的にはどのみち勝てなかったでしょう。私も同じ条件であれば、一応は説得を試みるけれど返り討ちに遭うと思う。いずれにしても結果は同じですが、教えられたと思っているなら間違いです。 結論はいつものとおり「下手糞が居るから」に行き着くのですが……。 JOIN禁止について 「JOIN禁止」が正しい場合がある。 それはJOINされるデータがアプリケーションサーバにキャッシュされていて、その一貫性が何らかの形で保証されている場合。 そもそも、せっかくキャッシュしているのに、それを使わずにJOINして取り直
関連チェックはトリガーで - SQLer 生島勘富 のブログ
有効期限付きのマスターを使うことが増えてきましたが、これらはトリガーでチェックすることが効率的です。 トリガーならエラーを返すことができる。 サロゲートキーを利用した以下の様なテーブルがあったとします。 CREATE TABLE Item ( ID int IDENTITY(1, 1) NOT NULL, CD nvarchar(20) NOT NULL, 名前 nvarchar(255) NOT NULL, ステータス int NOT NULL, 有効期限開始 datetime NOT NULL, 有効期限終了 datetime NOT NULL ) go ALTER TABLE Item ADD CONSTRAINT pkItem PRIMARY KEY (ID
データ量とインデックスについて - SQLer 生島勘富 のブログ
新人研修の季節ですね。 以前、インデックスについてカラオケ本をイメージして考えましょうと書きましたが、新人研修などでは、あまり難しいことを考えずイメージを持つことが非常に重要です。 是非、新人研修の前後で読んでいただければと思います。 もちろん、カラオケ本とRDBMSのインデックスのアルゴリズムはまったく違いますが、あくまでイメージなので、揚げ足取りは勘弁してくださいね。 かなり前のことになりますが、カラオケ本の続きです。 パフォーマンスについて ・売上データが入った1000万件のテーブルＡがあり、2011年5月17日のデータはＡテーブルは1000件入っています。 ・売上データが入った10万件のテーブルＢがあり、2011年5月17日のデータはＢテーブルは5000件入っています。 それぞれのテーブルについて2011年5月17日の集計処理を行うとすると、インデックスがあるのとないのでは、パフォ
ストアドプロシージャについて質問を頂いたのでまとめ - SQLer 生島勘富 のブログ
試用版を公開しました Oracleの試用版をダウンロード SQLServerの試用版をダウンロード セミナー情報 9月17日にセミナーでお話しさせて頂きます。 首都圏の皆様、無料ですのでよろしければご参加ください。 http://www.microsoftplatformready.com/jp/Home.aspx ストアドプロシージャ使った開発 まず、ストアドプロシージャを使うのは、UIとDBを完全に疎結合にすることを目的としています。勘違いされるのが多いのは、ストアドプロシージャはパフォーマンスが必要な複雑な処理で使うとか、そういう先入観があるからでしょうか。 UIがアクセスするのはストアドプロシージャのみです。 同じ処理があったとしても、必ず、UI側がアクセスする処理に対して1つストアドプロシージャを作り、他では利用しません。 UI用のストアドプロシージャが、処理用のストアドプロシー
SQLの句や述語で使えるもの２ - SQLer 生島勘富 のブログ
ご意見頂戴して、昨日の表を修正しました。 SELECT句、ORDER BY句で、テーブル関数は最終的にはサブクエリーにするので微妙なのですけれど、×としました。 普通は使わないので△の方が正しかったような気がするが……。この辺は微妙です。 エクセルファイルはこちらです。 句述語2.xls
インデックスについて - SQLer 生島勘富 のブログ
インデックスが分かってない人が非常に多い。 現実にあった例で、60カラムあるテーブルに、前から3つずつの複合インデックスを20個作るとか、30カラムを1つの複合インデックスにするとか、意味が分かっていない人が非常に多くいます。 ※ 詳しい人へ。ここでは、インデックス = B-Treeインデックスと考えてください。 インデックスとは インデックスとは、そのままズバリ「索引」のことです。 身近な例ではカラオケがあります。いわゆるカラオケ本がインデックス。リモコンで押す番号が主キー、流れる音楽・映像が実レコードと考えてみてください。 カラオケ本は「歌手名順」と「曲名順」の2つは最低限あると思います。 これらは、 歌手名順は、「歌手名・曲名」の組み合わせの複合インデックス。 曲名順は、「曲名・歌手名」の組み合わせの複合インデックス。 と考えることができます。 想像してみてください。小学生でも「アン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
