JavaDB(Derby)でのNOT NULL制約の解除 - きしだのHatenaなんか他のDBと違うのでメモ ALTER TABLE my_table ALTER COLUMN my_column NULL;
コーソルDatabaseエンジニアのBlog
コーソル DatabaseエンジニアのBlog へようこそ コーソル DatabaseエンジニアのBlogでは、 コーソル所属のエンジニアがOracle Databaseを中心としたDatabaseに関わる技術情報を発信しています。 コーソルでは、Oracle Databaseをはじめとするデータベース全般に関わるサービス（コンサルティング、設計、構築など）、オラクル製品のプロダクトサポートサービスを提供しています。 また、不定期で無償の技術セミナーを開催しています。 株式会社コーソル - サービス案内 株式会社コーソル - セミナー情報 コーソルでは、Oracle Databaseスペシャリストになりたいエンジニア、 Oracle Database技術を活かして働きたいエンジニアを絶賛募集中です。 コーソルについて知るためには・・・ 株式会社コーソル - 会社情報 人事ブログ - 『コー
Flywayで簡単DBマイグレーション | DevelopersIO
Flywayとは FlywayとはDBマイグレーションフレームワークです。 複数人でのアプリケーション開発時のDBマイグレーション作業を素早く手軽に行うことができます。 MavenやAnt、APIやコマンドラインツール形式で提供されており、柔軟に対応することができます。 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.4 MySQL : 5.5.15 flywayを使ってみよう 環境設定 flywayはMavenやAPIからも使用できますが、今回はCommand-line Toolを使ってみましょう。 ここからCommand-line Toolをダウンロードして解凍しておきましょう。 次にテストで使用するデータベースを用意します。今回はMySQLを使用しました。 mysqlを起動し、コンソールからデータベースを作成しておきましょう。 mysql>
DBの世界に起こる変革 | エンタープライズエンジニアの独り言
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
データベースコンサルタントのノウハウちょい見せ SSDに関しての記事の紹介と、SSDとDBに関して個人的な見解
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります http://techtarget.itmedia.co.jp/tt/news/1209/18/news06.html にある記事 ～ 期待した効果が見込めないことも ～ 「SSDを使ってはいけない6つのケース」がためになったので、要約とデータベースを想定して追加考察してみます。 長くない記事なので、良かったらtechtargetの会員になって読んでみることをお勧めします。 記事の要約(一部私の補足も追加しています) １ 読み込み集約型ではないアプリケーションにはSSDを使ってはいけない・・・書き込みが多いシステムには向かない。 ２ 高度か
アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である
［DB高速化］対策適用が裏目に出る、導入して分かった禁じ手
出典：日経SYSTEMS 2012年1月号 pp.62-67 （記事は執筆時の情報に基づいており、現在では異なる場合があります） さまざまな技術を組み合わせてシステムを開発・改善する。そのためには、組み合わせる技術の「かたち（特徴）」の把握が欠かせない。現場への適用によって明らかになったDB高速化策のアンチパターンを、技術の仕組みと共に解説。その上で、技術の特徴を生かした使い方を紹介する。 ユーザーの情報システム活用が多様化し、DBサーバーが扱うデータ量は膨大になり、システムへのアクセス数も急速に拡大している。データ処理のリアルタイム性を求められるケースも増えている。その結果、運用中のDBサーバーを高速化するニーズは、ますます増大している。 こうしたユーザーのニーズを受け、DBの高速化を図るための製品や技術も続々登場している。例えば、最近、システム開発現場での適用や検証が進んでいる主な高速
Big Sky :: VimでDBが操作できる vdbi-vim 作った。
DB操作ツール Emacs DBI を作ってみた - 技術日記＠kiwanami このツールの目的は、クロスプラットフォームで便利なDB操作環境を実現することです。 pgAdmin や MySQL Query Browser のようなGUIの良さをCUIで実現してみようとしてみました。すなわち、ぼくのかんがえたさいきょうのDBツールです。ちなみに、このツールにとってEmacsはただの実行環境です。Emacs使わない人でも使うと便利だと思います。 http://d.hatena.ne.jp/kiwanami/20120305/1330939440 VimもーVimもー！ って事で作りました。 mattn/vdbi-vim - GitHub Database client for Vim https://github.com/mattn/vdbi-vim Emacs版はepcというRPCプロト
DB操作ツール Emacs DBI を作ってみた - 技術日記＠kiwanami
去年からほそぼそと作ってきた、EmacsからDBを操作できるツール Emacs DBI を紹介します。 Emacs DBI の簡単な紹介 このツールの目的は、クロスプラットフォームで便利なDB操作環境を実現することです。 pgAdmin や MySQL Query Browser のようなGUIの良さをCUIで実現してみようとしてみました。すなわち、ぼくのかんがえたさいきょうのDBツールです。ちなみに、このツールにとってEmacsはただの実行環境です。Emacs使わない人でも使うと便利だと思います。 データベース画面 e2wmで3ペインの画面 機能概要 以下のような機能があります。 EmacsとDB接続可能なPerlが動けばターミナルでも何処でも動く DB定義、テーブル定義がすぐ見れる auto-complete によるSQL補完 接続先DBにからキーワード、型名、テーブル名、カラム名など
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
命名法 - 主キーはサロゲートキーで、テーブル名はナチュラルキーで（笑） - SQLer 生島勘富 のブログ
完全に新規の案件というのは本当に少ないので、実践できることはほぼない理想論ですが、私の理想とするテーブル構造と命名法です。 まずは、サロゲートキーについて サロゲートキーというのは業務上意味のないキーのことです。 例えば、生徒テーブルは、年次・クラスID・生徒番号で一意になるとしましょう。 この「年次・クラスID・生徒番号」の複合キーを主キーとせずに、システム側で採番した一意な値を主キーとすることをサロゲートキーといいます。 「年次・クラスID・生徒番号」はナチュラルキーといいます。 基本は全テーブルをサロゲートキーにする方が効率的です。 サロゲートキーを使わない例外 私なりの基準は関係テーブルの場合、他に情報がない場合サロゲートキーは使いません。 例えば ■ 生徒テーブル ID 年次 クラスID 生徒番号 名前 生年月日 …… ■ 科目マスタ ID 名前 …… ■ 履修マスタ（サロゲート
RDBMSをタバコ屋さんで説明 - SQLer 生島勘富 のブログ
勉強会に参加さてもらい、次の勉強会でお話しすることになったので宣伝です。 前の勉強会では以下の様な実験が話題になっていました。 http://www.doaplus.com/html/bun/bun03_20051101.html まあ、極めて当たり前の結果です。 5000万件が500万件になるというのは、データを横に非正規化すると明細テーブルが要らなくなるから件数が少なくてすむという意味らしい（爆笑）。 非正規化したテーブルに、更に足りない情報をJOINして得ようとすると、効率的なSQLを書くことが困難になって、非常に実行速度が遅くなる。 この結果から「なんでこの項目を非正規化しておかなかったんだ！」っていう連中が出て、テーブル構造はどんどんCOBOLのファイルレイアウトに近づいて行く。 要するに、JOINしたら遅くなると感じるのはテーブル構造が間違っているためですが、その間違った構造を
いますぐ実践! Linuxシステム管理
「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
津島博士のパフォーマンス講座 第5回 オプティマイザとオプティマイザ統計の収集について | oracletech.jp
今回は、オプティマイザ統計（Statspackなどで収集する統計情報と区別するため、オプティマイザが実行計画作成のために使用するものをオプティマイザ統計と言うことにします）の収集について説明します。最近、次のようにオプティマイザ統計の収集ついて聞かれる機会がありましたので、ここで説明することにしました。 「コストベース・オプティマイザ（CBO）だけになったためにオプティマイザ統計の収集は必須になりましたが、オブジェクトが多いと収集時間も軽視することができません。かといって収集時間を短縮したいがためにサンプル・サイズを小さくしたり、収集頻度を減らしたりすることで実行計画が最適でなくなったら困ります。オプティマイザ統計の収集に対する指針などあれば教えてください。」 これには、こうすれば良いという明確な指針はないので、皆さん結構悩まれているのではないかと思います。これについて、私の考えをまと
DBアタマアカデミー 記事一覧 | gihyo.jp
最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す？（3） ミック 2011-04-01
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Keynote
SQLer 生島勘富 の日記