タグ

DBに関するhikazohのブックマーク (18)

  • アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)

    毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした! この記事がすごく良かったので、触発されてブログ書く!!! developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき

    アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)
  • 正規化崩しの目的は「高速化」だけではない - 設計者の発言

    ひとつの事実が1か所にしか記録されないようにする――これはDB構造を正規化する際の基だが、このルールを意図的に違反すること(正規化崩し)で、効果的なDB構造が生み出されることがある。正規化崩しは高速化のためだけにあると思われがちだが、それ以外の目的もある。そのような正規化崩しのテクニックとして、「抽象化(汎化)」を取り上げよう。 説明の前に、正規化崩しに関して大事なことを言い添えておきたい。勘違いしている技術者がいるが、正規化崩しとは「正規化してから崩す」という意味である。来の正規形を経由せずに非正規形になっているとしたら、正規化崩しではなく、単なる「無手勝流」でしかない。 では、いったん正規化してから崩すことがなぜそれほど重要なのか。事前に「更新時異状(更新処理にともなって発生するデータの不整合)」に対処しておくためだ。正規化崩しにせよ無手勝流にせよ、そのままでは遅かれ早かれ更新時異

    正規化崩しの目的は「高速化」だけではない - 設計者の発言
    hikazoh
    hikazoh 2016/06/18
  • NAKAMURA Minoru's Diary (2016年4月)

    hikazoh
    hikazoh 2016/04/23
  • 他システムとのデータベース連携について - Qiita

    システムエンジニア Advent Calendar 2015 - Qiita 20日目の記事です。 システム開発をしていると、他システムのマスタやトランザクションデータが必要となる場合がよくありますね。 システム間のデータ連携としては、 リソース共有(データベース共有、ディスク共有) アプリケーション連携(RPC、Web API、MOM1) ファイル連携(CSV連携、etc) などの方法がありますが、ここではデータベース共有を実現するためのデータベース連携方式について考えてみたいと思います。 データベース連携方式について 既存システムがレガシーであったり、違うベンダーが構築したサーバーであるなどの理由で、新機能や拡張機能を別のサーバー上で新システムとして構築する場合があります。もちろん、データベースも新たに用意する場合が多いのですが、その場合は既存システムには極力修正をいれない方針でデータ

    他システムとのデータベース連携について - Qiita
  • SIerといえばソースコードの自動生成だ!テーブルとEntityクラスを自動生成するサムシン(PostgreSQL版) - そこに仁義はあるのか(仮)

    これはPostgreSQL Advent Calendar 2015 - Qiitaの記事です。 昨日はsawada_masahikoさんのPostgreSQL開発の基動作まとめ - Qiitaでした! SIerといえば、ソースコードの自動生成ですね! 開発を進めていくうえで、コロコロと変わっていくテーブル構成。。。 そんな中で、まったくソースコードを触らずに(sqljavaも触らない!つまり誰でも!どんな人でも!!作業できる!!!) テーブル構築からデータ投入、さらにはEntityクラスを生成することが出来るツール(mavenプラグイン)を、今のプロジェクトで使っているので、それの紹介と使いかたを説明します。 いろんなDBに対応しているけど、今のプロジェクトではPostgreSQLを使っているので、今回はPostgreSQL版の使いかた説明です!*1 なお、今回使っているPostgr

    SIerといえばソースコードの自動生成だ!テーブルとEntityクラスを自動生成するサムシン(PostgreSQL版) - そこに仁義はあるのか(仮)
  • jOOQ (Java Object Oriented Querying) の使い方の紹介 - 愛と勇気と缶ビール

    jOOQ (http://www.jooq.org/) についてのメモ。 jOOQは、type safeかつdatabase orientedなクエリビルダーである。 database orientedなので、「アプリケーションからDBのことなんて全然意識したくないねん」的な思想に基いて作られた類のプロダクトとは異なり、思い通りのSQLを生成できるようになっている。 以下gradle前提で。version等はよしなに。 gradle dependenciesはこんな感じ compile 'org.jooq:jooq:3.7.1' compile 'org.jooq:jooq-meta:3.7.1' テーブル等に相当するクラスをgradle taskから生成するためにbuildscriptのdependenciesにも以下をかいておく classpath 'org.jooq:jooq-cod

    jOOQ (Java Object Oriented Querying) の使い方の紹介 - 愛と勇気と缶ビール
  • EntityFramework(12):行の挿入、削除:Gushwell's Dev Notes

    前回、データの更新については、説明しましたので、今回は、行の挿入、削除の例を示します。 行をデータベースに挿入するには 、以下の手順を踏みます。 送信する列データを含む新しいオブジェクトを作成します。 データベース内の挿入先テーブルに関連付けられた EntityFramework Table コレク ションに新しいオブジェクトを追加します。 データベースに変更内容を送信します。 コードにするとこんな感じ。 using (var db = new NorthwindContext()) { Category cat = new Category { CategoryName = "Side Dish", Description = "salad, croquette, tempura, cooked beans", }; db.Categories.Add(cat); db.SaveChan

  • 1日に100万レコード増える場合のテーブル設計

    MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

    1日に100万レコード増える場合のテーブル設計
  • InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記

    MySQLでスレーブを複数台並べている。 負荷増加やサーバ障害で新規スレーブを追加したい。 で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。 それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。 というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。 クエリを実行して主要テーブルのIndexをロードする 低い振り分け比率でサービスに投入してしばらく待つ tcpdump + (mk|pt)-query-digest等で既存スレーブのクエリを流し込む 基的にサービス投入前の完璧なウォームアップは無理ゲーなので、 普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、という

    InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記
  • リレーショナルデータベースの仕組み (3/3) | POSTD

    データマネージャ このステップで、クエリマネージャはクエリを実行するので、テーブルとインデックスからデータを取得する必要があります。そこでデータマネージャに対してデータを取得するよう要求するのですが、ここで次の2つの問題が発生します。 リレーショナルデータベースはトランザクションモデルを使用しています。この場合、「いつでも・どんなデータも取得できる」というふうにはいきません。どこか別の場所で、ここに格納されているデータを同時に使用したり更新したりしている可能性があるからです。 データの取得は、データベース内で実行する処理の中で最も時間のかかるもの です。従ってデータマネージャはそれを見越して、メモリバッファにデータを取得しておき、それを保持しなければなりません。 このセクションでは、リレーショナルデータベースがこの2つの問題にどう対処しているかを説明します。なお、データマネージャがデータを

    リレーショナルデータベースの仕組み (3/3) | POSTD
  • リレーショナルデータベースの仕組み (2/3) | POSTD

    クライアントマネージャ クライアントマネージャは、クライアントとの通信を扱います。クライアントとは、(Web)サーバであったり、もしくはエンドユーザ、またはエンドアプリケーションであったりします。ここではJDBC、ODBC、OLE-DBといった良く知られる一連のAPIを介してデータベースにアクセスできる様々な方法が提供されています。 また、データベースアクセスのための専用のAPIも提供されています。 データベースと接続する手順は以下の通りです。 マネージャは最初に 認証を行い (ログイン情報とパスワードの確認)、次にデータベースにアクセスできる 権限 を持ち合わせているかチェックする。これらのアクセス権はDBAによって規定されている。 その後、クエリを管理できるプロセス(もしくはスレッド)が利用可能かチェックする。 データベースに高負荷がかかっていないかどうかも確認する。 要求されているリ

    リレーショナルデータベースの仕組み (2/3) | POSTD
    hikazoh
    hikazoh 2015/09/16
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
  • NativeQueryじゃだめ?〜JPAクエリ表現ごとのパフォーマンス比較 - Dev3TechHack

    このエントリはJavaEE Advent Calendar 2012の20日目です。昨日は@den2snさんのJavaを知らない世代が今からはじめるJavaEE開発でした。明日は@javaflavorさんです。 先月、岡山を訪れた時、Javaエバンジェリストである寺田さん(@yoshioterada)に「今仕事でやってるプロジェクトにJPAを導入したんですが、JPQLになじめなくって、素のSQLをNative Queryで投げてるんです。」という話をしたら、「Native Queryはパフォーマンス的に良くなかったはず…」との情報を頂きました。それが当なら、今のプロジェクトが危ない!正確に言うと、今のプロジェクトにJPAを持ち込んだ自分の身が危ない! ということで今回は、JPAに用意されている、Native Query、JPQL、criteria API 、それぞれのAPIのパフォーマン

    NativeQueryじゃだめ?〜JPAクエリ表現ごとのパフォーマンス比較 - Dev3TechHack
  • 巨大なバッチを分割して構成する 〜SQLバッチフレームワークBricolage〜 - クックパッド開発者ブログ

    トレンド調査ラボの青木峰郎(id:mineroaoki)です。 好きなRubyのメソッドは10年前からString#slice(re, nth)ですが、 最近はRubyよりCoffeeScriptとSQLのほうが書く量が多くて悩んでいます。 今日はわたしが開発している「たべみる」の背後で働いている 巨大バッチの構成について話したいと思います。 たべみるのバッチは約3000行のSQLで構成されており、 処理時間が1日で4時間程度かかる、そこそこの規模のプログラムです。 このバッチ処理プログラムをBricolage(ブリコラージュ)というフレームワークで構造化する手法について説明します。 「たべみる」とは まず最初に、「たべみる」がどういうものなのかごく簡単にお話ししておきましょう。 「たべみる」は企業のみに提供しているB2Bの分析サービスで、 クックパッドレシピ検索の分析をすることができま

    巨大なバッチを分割して構成する 〜SQLバッチフレームワークBricolage〜 - クックパッド開発者ブログ
  • 第7回 Springの宣言的トランザクションのしくみ【AOP】 | DevelopersIO

    よく訓練されたアップル信者、都元です。長雨が続いたと思ったらこの晴れ間。夏っすね。止まってしまわないうちにガンガン書いて行こうと思います。 Springによるトランザクションの実現方法を理解する さて前回、@Transactionalというアノテーションを付与することにより、宣言的にトランザクション制御を記述できることを学びました。 @Autowired UserRepository userRepos; @Transactional public void execute() { // 成功するDB書き込み操作 userRepos.save(new User("torazuka", "$2a$10$fx33wHST4ecwp53MB5QvROQtIYwkdCU2O3XJK6LuCmm415dRncluC")); // からの失敗 throw new RuntimeException();

    第7回 Springの宣言的トランザクションのしくみ【AOP】 | DevelopersIO
  • MySQL・PostgreSQLユーザーグループ(MyNA・JPUG)合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」

    表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に!」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで

    MySQL・PostgreSQLユーザーグループ(MyNA・JPUG)合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
  • DBの基礎 - コネクションプーリングについて

    コネクションプーリングについて、わかっていないことが多すぎたので、ちょっとだけ調べたことをメモで残しておきます。 今はまだ触りレベルしかわかっていなのいので、もう少しちゃんと分かるようになりたい! 😀 [スライド] データベースの羅針盤 コネクションプーリングを調べている過程で偶然見付け足資料 『データベース技術の羅針盤』。 とにかくわかりやすくて、俯瞰的にDBの業界を知ることができる資料。すばらしすぎる。 🎂 コネクション・プーリングとは?DBのコネクションを一定数確立しておいて、それを使いまわす手法のこと。 DBへの接続に必要となるオーバーヘッドをカットしてWeb/DBの双方の負荷を下げる。 また、WebとDBの接続を使いまわすことで同時接続数を節約する。 用意した、コネクション数を超えたアクセスは、コネクションに空きがでるまで待たされる。 以下はOracle関連の話ですが、基

    DBの基礎 - コネクションプーリングについて
  • 書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL

    来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり来どの

    書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
  • 1