BigQueryで150万円溶かした人の顔 - Qiita
※ かなり前の記事ですが、未だに引用されるので一応追記しておきます。タイトルと画像がキャッチーなのはちょっと反省していますが、これを見てBigQuery使うのを躊躇している人は多分あまり内容を読んでいないので気にする必要はないです。自分は当時の会社でも今の会社でも個人でも普通にBigQuery使っていて解析用データなどはBigQueryに入れる設計をよくしています。また、アドベントカレンダーだったのでネタっぽく書きましたが事前に想定できる金額です。 ※ 代役：プロ生ちゃん（暮井 慧） 巷のBigQueryの噂と言えば「とにかく安い」「数億行フルスキャンしても早い」などなど。とりわけ料金に関しては保存しておくだけであれば無視できるほど安く、SQLに不慣れなプロデューサーがクエリを実行しても月数ドルで済むなど、賞賛すべき事例は枚挙に暇がありません。 しかし、使い方によってはかなり大きな金額を使
Realm meetup #7 で発表をしてきました #realm_jp - @numa08 猫耳帽子の女の子
Realm meetup #7 で「Realm 正しく使うには」と題して発表をしてきましたので、資料と補足のまとめをします。 realm.connpass.com 資料 タイトルについて タイトルは「Realm を正しく使うには」としましたが、内容はコンテキストに依存をします。つまり、現場によっては正しさが異なります。 例えば、スレッド間通信やコンポーネント間通信の実現をするため、私は RealmObject の識別子やクエリを共有する方法を紹介させて頂きました。しかし、実際には独自のオブジェクトへ展開し、 Realm 管理下から外す手法が適している場合もあります。 自分で実装をする際にはどの方法が適しているのかを考えてから、資料を参考にしていただけると有り難いです。 キャッシュに利用するってどういうことですか？ 発表では、 Realm をキャッシュに利用していると説明をさせて頂きました。
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
データモデリング入門－astah*を使って、TMの手法を使う－
情報システムを効果的に活用できる様に、企業が有している情報を分析する手法が有ります その一つであるTMという手法と、astah*という道具を用いてデータモデルを書いて分析するための手引きです 以前にある人向けに作成しましたが、せっかくなので公開しておくことにしました
論理削除が云々について - mike-neckのブログ
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
データベース設計についての、僕の知っていることをちょこっと(2) - mike-neckのブログ
こんにちわ、みけです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass この勉強会に出られないので、データベース設計のことについて色々と言いたい放題を書くエントリーの2回目です。 本日はn対nのリレーションを作るときに絶対にやることを書きます。 なお、別に大した話ではありません。 n対nのリレーションにするなら、リレーションそのものをエンティティにする 前回のエントリーでテーブルにはマスター(リソース)とイベントがある的な話をしたわけですが、実はマスターについて何も語っていませんでした。 で、マスター(リソース)について書きたいところではあるのですが、リソースについて書こうとすると絶対にn対nのエンティティ間の関連が出てきてしまうので、先にn対nの話をしておきたいと思った次第です。 n対nの関係の例 ここでは例として、ある個人スポーツのアス
データベース設計についての、僕の知っていることをちょこっと - mike-neckのブログ
こんにちわ、みけです。 なんか、こんなイベントが開かれるらしいです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass 僕の方は @mike_neck http://t.co/oZmo4aDp1v こっちとダブルブッキングです！— だいくしー (@daiksy) 2015, 1月 29 ということで、しょぼちむには泣いてもらうことにして(というか、僕が申し込んだ時点で補欠だった)、 参加できないなりにデータベース設計について僕が知っていることと必ずやっていることを少しだけ記述しておこうと思いました。 なお、僕の考えも正解とは言えませんので、マサカリ歓迎です。ただ、このブログコメントが承認制なので、僕が気づかなかったらごめんなさい(m´・ω・｀)m ｺﾞﾒﾝ… なお、しょぼちむがいる会社に川島さんという方がいらして、僕が知っていることを非常に丁
DBUnitを使って、ユニットテストのテストデータを作成する
弊社ではテストのエビデンスとして、JUnitの結果とコードのカバレッジを提出するルールにしておりますが、開発者それぞれの環境でallTestをするようなこともあります。その時に環境によっては、マシンのスペックが悪くallTestにけっこう時間が掛かってしまうこと、またその影響でマシンの負荷が高くなり、他の作業を並行してやれず仕事にならないようなことがありました（注1）。その対応としてJenkinsにブランチのallTestが流せるジョブを作って対応しました。 あと、Jenkinsのバージョンはこまめに更新した方が良いなと実感しました。バージョンアップする前はビルド、AllTest、ページビューなどが結構遅くて、周りの人からも遅いという声があがっていました。改善として、サーバのスペックをすぐに上げることは無理そうだったので、jvmのチューニングをしたりしましたがさほど効果はなく、Jenkin
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ
あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リレーショナルデータベース入門―データモデル・SQL・管理システム - kagamihogeの日記
RDBMSの知識不足を感じて以来、ここのところその勉強に力を入れている。学習方針は、 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ - kagamihogeのblog等の著書のミック氏が推奨している方法で、理論と実装の両面から進めている。俺の場合、後者は、Oracleで主にパフォーマンスの観点から基本的原則を確認することをやり、前者は、本書のような書籍を通して行っている。 本書は、コンピュータサイエンス初年度の講義の教科書を想定して作られている。そのため、コンパクトながらもトピックの網羅性、それになにより各章が独立していながらも本一冊を通してみると一貫性が保たれているのが素晴らしい。また、章から章への論理展開が極めて明快なので読みやすい。もっとも、これは俺がある程度の実務経験という下地と、まがりなりにもコンピュータサイエンスの学部経験があるからこそ、の部分もあるだろうけど
SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
昨日のエントリ「SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる（「'OR'1」）ことを示しましたが、@masa141421356さんと、やまざきさん（お二人とも拙著のレビュアーです）から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います（id側に「'OR」, pwd側に「>' 」で6文字）。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
ドキュメント指向のNoSQLデータベース（CouchDB、MongoDB）編
書籍紹介 本連載は下記書籍から第5章を基に、＠IT向けに再構成して掲載しています。 目次 序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基本概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 本連載は書籍『NOSQLの基礎知識』（リックテレコム刊、ISBN：978-4897978871）で解説されている内容から一部を抜粋し、本連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基本概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基本概念から、各プロダクトの特徴を理解できる内容になっていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://sea.jp/Events/symposium/ss2009/contents/07-Modeling/ss2009-modeling-slide-tokimoto.pdf
データベース設計徹底指南
SQL Server アンチパターン MVPComCamp
DBスキーマもバージョン管理したい！
