タグ

databaseとprogrammingに関するtoriaezuのブックマーク (10)

  • 作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな

    さて、アルゴリズムの勉強のしかたと、ラムダ計算の勉強のしかたの目星をつけました。 アルゴリズムの勉強のしかた - きしだのはてな ラムダ計算の勉強のしかた、プログラム意味論 - きしだのはてな これでここで書いたプログラムの理論の基礎は勉強できたことになるんじゃないかと思います。 プログラムの理論とはなにか - きしだのはてな ところで、プログラムの勉強地図としてこういう図を書きました。 で、ハードウェアまわりについても、プロセッサを支える技術やネットワークはなぜつながるのかでひととおり勉強したとしましょう。 じゃあ次は、アジャイルか?テストか?UIデザインか?となるわけですが、やはりプログラマなら、プログラムの作り方や使いやすさの前に、作るプログラムの機能や性能で勝負したいじゃないですか。 いい感じに関数が分割できるよとか、読みやすい名前がつけれるよとか、効率よく仕事して定時に帰れるよと

    作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • 楽観的同時実行制御 | ALT

    tsが更新列。不思議な関数tseuqalが呼び出されていますが、これはタイムスタンプ値が異なるとエラーにするSQL Server固有の関数です(更新されないでエラーになる)。=で判定してしまうと、「成功。0行更新しました」とご機嫌に言われてしまうから。IDが間違っていたのか、タイムスタンプ列が違っていたのかが区別できないことになってしまうので。 しかし.NETではSqlTypesにrowversion型はないのだ どうやら、Microsoftとしては使ってほしくはないらしい。MSDNからも、版が上がるたびに徐々に記述が減っていく。更新したい列全部をWHERE句に入れろ、というアプローチを推しているらしい。ADOや、ADO.NETのDataAdapterはこのアプローチです。しかしBLOBがあったらどうするんだ?! NULLは? もうめちゃくちゃ大変だし、UPDATEのトレースを取ると、ほと

  • トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis

    データベースの同時実行性の定義データベースにおける同時実行性は、同時に共有データにアクセスしたり、 共有データを変更したりする複数プロセスの機能性として定義することができる。 互いにブロックすることなく同時に実行できるユーザプロセス数が多いほど、 データベースシステムの同時実行性は高いといい、データの変更プロセスによって、 他のプロセスがその変更データを読み取りできなかったり、 データの読み取りプロセスによって、他のプロセスがそのデータを更新できない場合、 同時実行性が低いという。また、複数プロセスが同じデータを同時に変更しようとすると 常にデータの整合性が損なわれるような場合も、同時実行性が低いと言える。 同時実行性が低くなる状況に対処する方法データベース システムで同時実行性が低くなる状況に対処する方法は、 使用している同時実行制御がオプティミスティック(楽観的)*1かペシミスティック

    トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis
  • techbank.jp - このウェブサイトは販売用です! - techbank リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • システム開発実践講座

    システム開発でデータベースを使う時には、売上伝票のようにデータを鑑部と明細に分けることがよくあります。 前回までに、鑑部を表形式にして、その後にテーブルの正規化を行いました。 次は明細部分の正規化が必要ですが、 その前に、今回は明細を表形式にするところから始めましょう。 これまでに行っている部分の復習です。 売上伝票を鑑部と明細部に切り分け、 関連付けるために、 明細部に「伝票No」の項目(列)を加え、 明細部の各行を、一意に識別するため、主キーとして「明細No」を加えた状態がこれです。 ・明細部 *一意とは、同じデータが他に無く、重複しないことです。 *主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。 *明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。 思い出しましたか? やっと準備が整いましたw リレーショナルデータベ

    システム開発実践講座
  • リレーショナル・データベースの世界

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • 【YQL 速攻レビュー】米 Yahoo! が SQL っぽく色んなデータを取ってこれるAPIを出した - てっく煮ブログ

    Yahoo!Yahoo! Pipes みたいに自由度が高くて、またちょっと毛色が違うサービスが出てきた。題して、Yahoo! Query Language。YQL と呼ぶようだ。SQL 風の言語を REST で投げて、結果を XML や JSON で受け取ることができる。具体的にやってみないと分かりにくいので、とりあえず試してみた。RSS からデータ取得YQL を使って RSS から最新のタイトル10個を取ってきてみる。こんな YQL になるらしい。 select title from rss where url='http://d.hatena.ne.jp/nitoyon/rss' rss テーブルに対して select を発行している。実際にこの YQL を試すには YQL 用の console を利用するとよい。(※要ログイン)console の左上に YQL を入力して

    toriaezu
    toriaezu 2008/12/15
    SQLなら書けるぞ!
  • わんくま同盟

    今回の勉強会情報 今回はAmazonのMillsさんをスペシャルスピーカーにお招きして、AmazonWebサービス戦略などについてなどしゃべっていただきます。 また新たな試みとしてパネルディスカッションを行います。パネラーも募集していますので、手を挙げてもらえれば。 是非皆さん奮ってご参加ください。 またセッションの参考にもいたしますので是非ネタの提供もお願いします。 それでは当日みんなで楽しくやりましょう。(^^ 開催日・場所 2007/02/03(土) 10:30~18:00 会場情報:東京 マイクロソフト株式会社 社 新宿オフィス 11F #119(先着45名) 住所:東京都渋谷区代々木 2-2-1 小田急サザンタワー Telephone 03-4332-5300 アクセス情報 : JR新宿駅 南口 徒歩3分 JR代々木駅 北口 徒歩5分 ステップバイステップによる会場までの行き

    toriaezu
    toriaezu 2008/12/14
    勉強する
  • SQLで集合演算:CodeZine

    はじめに SQLが集合論に立脚する言語であるということは、この連載で一貫して強調してきたテーマの一つです。その特性のゆえに、SQLは「集合指向言語」と呼ばれていますし、実際、集合的な観点から見たときに初めて、その強力さが理解できると私は考えています。しかし現実には、SQLのこの側面は長らく無視されてきました。 その背景には、SQLにも責任の一端があります。というのも、SQLはちょっと前まで、高校で習う程度の基的な集合演算子すら持っていなかったからです。和(UNION)こそSQL-86からの古参ですが、交差(INTERSECT)と差(EXCEPT)が標準に入ったのはSQL-92ですし、除算(DIVIDE BY)が未だに標準化されていないことは、前にも述べました。だから、SQLが言語として不完全だという批判は、理由のないものではなかったのです。 しかし、現在では標準SQLに基的な集合演算子

  • 1