SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
nullについて最後まで考える(1) --- T字形で消せるnull，消せないnull - 極北データモデリング
正美氏とかDateの本を読むと、Codd論文を理解するとnullの存在が許せなくなるのだなあ、と思う。 私はこのnull徹底排除の感覚が理解できていない。Codd論文読んだことないし。 比較演算や集計演算の対象に null が混入していると、直感に反する結果が出てくることがあるのはわかる。 同僚がnot null制約を付けていないのを見つけると「付けないとだめっすよ」と言ったりもする。 でも、これはわかった振りをしているだけなのだ。 nullがよくないのは当たり前として、あらゆるアプリケーションでnullを発生させないことができるのだろうか？ どうしても発生するケースがあるのだとすれば、どのnullはあってもよくて、どのnullはあってはならないのか？ where句に出現するnullと、サブクエリが返すnullと、アプリケーションに返されるnullと、罪の重さは全部同じなのか（違うんじゃな
11月の活動報告
先日、db tech showcaseと北海道データベースDAYでプレゼンを行ったので、例によってSlideShareで公開してある。既にTwitterで呟いたので既にご覧になった方も多いかも知れないが、改めてブログでも紹介しておこうと思う。 あなたが知らないリレーショナルモデル（@db tech showcase） まずはdb tech show caseで使った資料の紹介だ。今回は50分という時間の短さだったので、伝えたいことをギュッと凝縮した内容になっている。この資料で主に伝えたかった内容は次のようなものだ。 リレーショナルモデルとは何か SQLとリレーショナルモデルの関係 リレーショナルモデルを使わないとどうなるか なぜリレーショナルモデルを適用できないか どんなときリレーショナルモデルを適用してはいけないか 4つ目については、ひとつ良い説明の方法を思いついたので、今回の資料にも盛
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
