Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
makopi23のブログ 「DBリファクタリング読書会 第三回」に参加しました
2012/8/30(木)「DBリファクタリング読書会 第三回」に参加してきました。 Atnd（告知ページ） http://atnd.org/events/31517 以下の書籍をターゲットとした読書会なのです。 ただ読書会といっても、みんなで集まって本を読むのがメインではなく、DBリファクタリングに関する発表や座談会が中心です。私は第１回から参加してますが、今日が第３回の開催でした。 会場は日本オラクル青山センターです。 ３回目の参加なのに今日初めて知ったんですが、オラクルの真ん前に神宮球場あったんですね。。。 ちょうどヤクルト戦が開催されてて、ラッキー７のイニング合間だったのかどうかよくわかりませんが、球場の近くから花火が盛大に上がってて、それをみんなでオラクル13Fから眺めてました。 あと当日の様子のブログは、他の方が既に数名、詳細に書いてくださっていますので、そちらが参考になるかと思
ブログを書くまでが読書会、 #dbrr DBリファクタリング読書会 第三回でのメモを公開しよう。 - #garagekidztweetz
ツイートSource: flickr.com via garage-kid on Pinterest DBリファクタリング読書会 第二回に引き続き、第三回にも参加してきました。 データベース・リファクタリングposted with カエレバスコット W アンブラー,ピラモド・サダラージ ピアソンエデュケーション 2008-03-26 Amazon楽天市場購入してみたはいいものの積読になっていた本書を読むとてもいい機会だと活用させてもらっています。 現状、わたしは少しづつ読み進めていて、今は「第六章 構造リファクタリング」が読み終わったところにいます。 第三回目の本読書会は、「第三章 データベース・リファクタリングのプロセス」をメイントピックとして行われました。 では、以降、わたしがとってきたメモのシェアになります。 Contents. 開会 @do_aki さん スポンサーセッション @y
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
削除フラグのはなし
6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
テーブルの分類について
TAKE^2 @_taketake @n3104 すんません。今ごろ見ました。2種類に分けちゃうのって難しいかもです。例えば、宿泊予約サイトなんかだと、サイト運営者、宿泊施設、エンドユーザーという登場人物がいるわけで、エンドユーザーのマスタは宿泊施設のトランザクションとも考えられるし、サイト運営者の（続く） 2011-06-13 23:12:55 TAKE^2 @_taketake @n3104 (続き)トランザクションは宿泊施設のマスタとも考えられるわけで。2つの登場人物しか居なかったときの名残といってもいいのかなと思っています。マスターとトランザクションって。下の登場人物が発生させたデータがトランザクション。上の登場人物が発生させたデータがマスタみたいな 2011-06-13 23:20:31
「ＤＢ構造を見直さない」というアンチパターン - 設計者の発言
システム開発プロジェクトの失敗原因のひとつに「システム刷新時に、ＤＢ構造を見直しせずにプログラムの言語だけを置き換える」というものがある。アンチパターンとまでは言えないとしても、クリティカルな問題をはらんでいる。にもかかわらず、いくつかの理由からこの方針は無批判に受け入れられるか、場合によっては歓迎さえされる。 なぜか。まず、システムの問題がＤＢ構造（帳簿組織）の悪さから来ているという認識を、ユーザーやシステム部門が持ちにくいため、その見直しが明示的に求められないからだ。また、必要なスキルを持った技術者が少ないため、開発側として（大手SIerでさえ）なるべく見直ししたくないのが本音だったりするからだ。いかにも問題がありそうに見えても「求められないから手をつけない」という理屈で通す。また、ＤＢ構造が多少おかしくてもエレガントなクラス構造でカバーできるから一刻も早くプログラミングさせてほしい―
「もうDBはこうなってますので」はもったいない - jfluteの日記
DB設計のアプリ最適な作業 引用記事：「アプリ寄りなDB設計者、インフラ寄りなDB設計者」 ※こちらの記事の内容を前提とします。 「データベース物理設計」と聞くと、 どんなことを想像しますでしょうか？ 大抵の人は、 データ型などを決定し論理モデルから物理モデルを作成して、 データ容量やその他パラメータなど、 インフラ的な調整をする設計と考えるでしょう。 まあ、それで正しいわけです。とても大事な作業です。 自分はこの「物理設計」に、 「アプリでの開発のし易さのための調整」を入れたい、 と考えています。 DB設計のインフラ最適な作業はかなり一般的な概念で 忘れられることはないですが、 「DB設計のアプリ最適な作業という概念」は、 あまり一般的とは言えないような気がします。 (物理設計が違和感あるなら別に他でもいい。 とにかくその概念がどこかに必要) 何を言っても、もう変えられません 現場でよく
テーブル設計 データモデリングのエッセンス（１） | システム設計日記
何回もデータベースを設計してきた。多くの失敗をしながら。その中から、こうすれば良い設計ができる、というデータモデリングやデータベース設計のノウハウが少し見えてきた。その要点をまとめてみる。 テーブルの役割を一つにする クラス設計と同じで、テーブルの役割は単純にすべきである。 関心のある情報のグループごとに別のテーブルに分ける。 例えば、商品にはさまざな属性情報がある。 ・仕様（色、サイズ、機能など） ・価格や割引ルール ・仕入れルート ・原価 ・在庫数 ・在庫場所 ・販売開始／販売停止の状態や予定日 など。 「商品」という一つの「なんでもテーブル」に情報を詰め込んで、アプリケーションプログラムのほうで、さまざまな検索条件を使い分けるのは、典型的なアンチパターン。 それぞれの情報ごとに別テーブルを用意して、ひとつのテーブルは、一つの関心だけを管理する設計が基本。 役割が一つのテーブルの特徴
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: データの削除は非推奨