タグ

sqlに関するwwolfのブックマーク (6)

  • 生島さんが考える最強の言語 SQL - ぐるぐる~

    生島さんが誰と闘っているのか知らないけど、ちょっと気になることをつらつらと。 SQLは最も高級言語 - SQLer 生島勘富 の日記 SQLは最も高級言語2 - SQLer 生島勘富 の日記 SQLとはなんぞや? - SQLer 生島勘富 の日記 高級*言語* どうも生島さんは、「SQL は高級言語!」と言いつつ SQL の処理系 (RDBMS) のことを高級だと言っているようです。 言語が高級であることと、処理系の最適化が手厚いことをごちゃまぜにして、この言語高級!と言うのはまずいんじゃないでしょうか。別に、RDBMS を操作するための言語として SQL でなくたっていいのです。例えば Tutorial D/Industorial D もあるし、LINQ を SQL に変換せずに直接 DB の操作を行うような RDBMS/Linq to X と言うのも考えられます。 ここではとりあえず、

    生島さんが考える最強の言語 SQL - ぐるぐる~
    wwolf
    wwolf 2010/11/30
    そうだよねぇ
  • PL/SQLのカバレッジツールを作ろう1 - SQLer 生島勘富 のブログ

    ストアドプロシージャでやるとカバレッジツールがないということが問題になるようです。 個人的には「別になくても良いんじゃない?」って思うけれど、なかったらストアドプロシージャは使えないと言われると、普及させたいと思う私は困ってしまう。簡単にできる範囲で作ってみよう。 SQL Server にするか、Oracleにするか。 私の探し漏れなのか、SQL Server についてはカバレッジが可能なAPIが見当たらない。Visual Stadio の高い Edition で出来るみたいだから公開しないのかな? Oracleはメジャーなツールでは PL/SQL Developer(25,000JPY)というツールがカバレッジに対応しているそうだが、フリーでないと使えないという人も多いようで(確かに開発者ライセンス25,000はちょい痛いね)フリーで公開できるレベルのものにするために横着する。全く一から

    PL/SQLのカバレッジツールを作ろう1 - SQLer 生島勘富 のブログ
    wwolf
    wwolf 2010/11/17
    カバレッジという考え方とSQLはあんまり馴染まないような気がするんだけど…
  • 第3回 テーブル設計のグレーゾーン~毒と薬は紙一重 (4)サロゲートキーVSナチュラルキー | gihyo.jp

    サロゲートキーVSナチュラルキー DBエンジニアの方なら、サロゲートキー(代理キー)という言葉をご存じでしょう。これは、テーブルへの入力データにある列を主キーとせずに、システム側で独自に割り当てるキーのことです(一般的には連番が使われます⁠)⁠。これに対して、入力データ自体の列を主キーにする場合はナチュラルキー(自然キー)と呼びます。 サロゲートキーは、基的には不要なものです。入力データに一意なキーが存在していればそれを主キーとして使うことで、普通は問題ありませんし、オートナンバリングの機能も長らく標準SQLには存在していなかったからです(そのため、今でも実装ごとにやり方はバラバラです⁠)⁠。しかし、以下のような業務要件の場合には、サロゲートキーを使うことを考えます。 ① そもそも入力データに主キーにできる項目がなく、データが重複している場合 ② 主キーの値が使いまわされる場合 ③ 主キ

    第3回 テーブル設計のグレーゾーン~毒と薬は紙一重 (4)サロゲートキーVSナチュラルキー | gihyo.jp
    wwolf
    wwolf 2009/10/04
    個人的には代理キーは好きなんだけどなー
  • SQLをより賢く使うための12のヒント - builder by ZDNet Japan

    あなたのユーザーはSQLについてまったく知らないかも知れないが、その価値についてはしっている可能性が高い。SQLはあらゆる場所で使われており、学ぶのも簡単で、SQLを使ったソリューションは実装も簡単だ。SQLをあまり使わないにしろ、よく使うにしろ、SQLを賢く使えば、エラーを避け、性能を向上させることができる。 多くのSQLは各ベンダー独自の仕様を持っている。以下で紹介するヒントはJetとTransact-SQLで使えるものだが、ほとんどのSQL製品はこれに似ている。 1: AccessのSQLウィンドウでJet SQLを利用する Accessユーザーは、クエリを作成するたびにSQLステートメントを作成している。ただ、彼らがそれを知らないだけだ。彼らが使っているクエリデザインウィンドウは、実際にはSQLを視覚的に表現したものだ。ほとんどのユーザーは、自分が必要とする適切なSQLステートメン

    SQLをより賢く使うための12のヒント - builder by ZDNet Japan
    wwolf
    wwolf 2009/07/01
  • suVeneのあれ: 俺的コーディングルール SQL編

    2007年01月19日 俺的コーディングルール SQLプロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード=大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す

    wwolf
    wwolf 2007/01/20
    こういうのはありがたい。
  • ホワット・ア・ワンダフル・ワールド SQL とか全然知らないんですが

    一応ルール型言語の研究者のはしくれとして違和感を感じたので. SQLに対する接し方 SQLは言語としては構造化以前のBASICレベルなので、複雑な事をさせたくない。1つのクエリが数十行あると、読みたくない。といって関数分けもできない。 ということで、複雑な処理は高機能な汎用言語上でやる。 SQL ってよー知らんのだけど,あれってまんま Prolog とちゃうん ? クエリの最適化かとも,Prolog プログラマならば誰でも無意識のうちにやってることだと思うしなぁ.なるべくバックトラックを減らすために,一気に探索範囲が絞られる順番にアトム (クエリ) を並べるとか. 逆に言うと,そういう下部の制御 (How) を意識しないといけないってのが,Prolog の (宣言型 (What) 言語としての) 致命的な欠点なんだけど.Java なんかに比べたら,はるかに高級な言語のような気が. まぁ,文

    wwolf
    wwolf 2006/11/08
  • 1