日本オラクル、4代目社員犬「キャンディ」入社式を開催 - 遠藤社長も登場 | 経営 | マイコミジャーナル
日本オラクルは10月15日、4代目となる社員犬「キャンディ」の入社式を都内のオラクル青山センターで開催した。 4代目社員犬キャンディと遠藤社長の2ショット キャンディは2010年7月23日生まれ(生後約3ヵ月)のオールドイングリッシュシープドッグ(メス)。出身地は徳島県。名前は同社社内での公募結果によるもので、「We Can Do IT」の「Can Do」の音韻がその由来となっているとのこと。 入社式でキャンディに辞令を交付した同社 代表執行役 社長 最高経営責任者 遠藤隆雄氏は「IT業界は "ドッグイヤー" と呼ばれるが、まさにそんな業界にふさわしい "ドッグ"」と語った。また、「ストレスが多いとされるIT業界において、キャンディのような "癒し" の存在は重要」とし、あらためて社員犬の存在意義を説明した。 なお、キャンディの勤務地は日本オラクル本社(オラクル青山センター)で、2010年
日本オラクル、Twitterを開始 - オラクル・アジアパシフィック＆ジャパン メディア・センター
Get Oracle news, views, and how-tos delivered to your inbox.
もう1つの、DBのかたち、分散Key-Valueストアとは
もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
特集:基礎から理解するデータベースのしくみ - 特集:基礎から理解するデータベースのしくみ：ITpro
「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない，といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが，基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの？ 基礎から理解するデータベースのしくみ（1） Ｐａｒｔ１ ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ（2） 基礎から理解するデータベースのしくみ（3） 基礎から理解するデータベースのしくみ（4） 基
PostgreSQL パフォーマンスチューニングまとめ - 徒然なるままにBlog
PostgreSQLをチューニングする機会があったので その時に調べたチューニング項目を備忘録として残しておきます。 バージョンの違いやサーバの規模などによっても 効果は変わってくると思うのであくまで参考程度のものですが。 ・shared_buffers 7系では8000〜10000程度まで引き上げる 8系では150000程度まで引き上げることが可能、100000程度が性能のピーク これに多く割り当てるよりOSのバッファ領域として使う方が性能が向上する テーブルサイズを割り出して設定するのがベスト 簡単に設定するなら搭載メモリ量の1/4、搭載メモリが多ければ1/2ぐらいでも可 ・max_connections 7系では256程度、8系では1000程度が性能のピーク ・work_mem(sort_mem) 適切なサイズに調整する、2048〜4096程度 プロセス毎
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
いまの気持ちをSQLで表すスレ:アルファルファモザイク
Begin transaction Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Select * into 俺 from 冷蔵庫 where 種類='酒' order by アルコール度数 Goto 便所 便所: Rollback INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れのドリルチンポ) INSERTINTOマンコVALUES(漏れの精液)
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本オラクル、4代目社員犬「キャンディ」入社式
candy