酔いどれ設計ナイト2019の発表資料です。
セイコーエプソン株式会社、萩原豊隆さんによる、新しいモデリング手法、 「動詞de!! モデリング�」のプレゼンテーションです。 ・ソフトウェアの振る舞いは動詞で表現できます。しかし今までのモデリング手順では、“動詞”を適切に扱えませんでした。例えば名詞つまり目的語に着目する一方で、付随する動詞を無視して振る舞いを漏らす。あるいは「○○制御」クラスのように振る舞いがすべて“制御”という言葉に隠れてしまう。いずれも動詞の取り扱いのまずさに起因します。 ・そこで目的語と共に動詞も同時にクラス図へ変換する手法を作りました。モデリングツールを使って、目的語と動詞の組み合わせをサクサクとクラス図に変換していきます。クラス図の良し悪しは読み上げて確認です。単純かつ明快なので誰もがセンスに依存せずにモデリングできるようになります。Read less
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
論理削除が奪うもの JPOUGのAdvent Calendar 12/10担当です。 12月 - 忘年会シーズンです。酒で記憶を失っている際に、怒ったとか、近くにいた人にカラんだとか、脱いだとか、毛を燃やしたとか、エレベーターホールにズボンが脱ぎ捨てられていたとか、会議室で靴が発見されたとか、そういう事件が多発する月ですね。皆様いかがお過ごしでしょうか。 微塵も記憶がない状態で、やらかした内容を色々な人から聞かされるにつけ、穴を掘って蓋してセメントで埋めてもらいたくなるのは常ですが、こういう時はどんな対処を取ればいいんでしょう。 得てしてロクでもない行動を取った時の翌日における参加者の記憶力の良さと来たらFlight Recorderも真っ青です。 なんとか失敗を無かったことにしたいと立ち回りたいですが、まあ無理です。各所にヒアリングを重ねれば重ねるほど確度と精度が高まります。エビデンスま
だいぶん前から延々とくすぶっているIDキー問題あるいはサロゲートキー問題なのですが、一時期下火になっていたのですが、また再燃している感もあります。それだけ奥深い問題なのかもしれません。 複合主キー「否定派」と「許容派」の論争 IDの設計についてのさらに突っ込んだ議論 生きているうちに自然キーvsサロゲートキー問題に決着を付けたい(1) ただ、読んでみると同じような話題のように思えても意外に論点が錯綜しており、交通整理が必要なのではないかと感じます。私が見たところ 有意キー vs 無意キー グローバルキー vs ローカルキー 公開キー vs 非公開キー 複合主キーあり vs 複合主キーなし というところが論点かな、と感じています。あまり一般的な用語法ではないところもありますが、個々人で微妙に定義が異なる気もするので、一旦この名前で呼ぶことにします。 まず、第一の論点「有意キー vs 無意キー
MySQL Performance Blogの翻訳。MySQLのようなリレーショナルデータベースと、ドキュメント志向データベースMongoDBでのスキーマデザインの違いについて。 2013/08/01 by Stephane Combaudon リレーショナルデータベースに慣れている人がMongoDBのようなNoSQLのソリューションを使うのは、面白いチャレンジになるだろう。そのうちのひとつが、スキーマのデザインだ。リレーショナルな世界では、正規化がいいとっかかりだが、新しくMongoDBのアプリケーションを作るときには、データ保存についてどうデザインすべきだろうか？ 簡単な例を挙げて、MySQL(というかあらゆるリレーショナルデータベース)でデータ構造をどう作るか、そしてMongoDBではどうかを見てみよう。個人情報(名前)とその人のパスポートの詳細(国籍と有効期限)を保存したい、という
『分散オブジェクト・アーキテクチャ／ドメイン指向アーキテクチャ』について考えるなかで、「永続化」への理解が深まった。というか、このアイデアについて人と話してもかみ合わない理由が分かった。とどのつまり、ぼくが独特な感覚を持つマイノリティだったのだ。 たぶん、ふつうのプログラマから見れば、おそろしくどうでもいいことにこだわっている、ように見えるだろう。 信仰告白 ぼくは現在主流の「データベースを使った永続化」が大嫌いだったんだ。ORMとか一体何なんだ。知らんわな。なんでプログラムを書くのにSQLを書かなきゃならんのだ。（※個人的な感じ方の問題です） 「RDBからSQLでデータをとってきてHTMLで整形して出力するPHPプログラミング」なんて二度とごめんだ。データベースのために働いてるみたいじゃないか。（※個人的な感じ方の問題です） 「データベースを使った永続化」が行き過ぎると「データベース中心
FC2ブログからMT5.2.7に引っ越す このブログも開発継続する気ないので引っ越… 開拓日誌ブログ上 me | コメント(0) Vyatta 6.6R1でやったーぶいっｖ もうルータ買わない！… 開拓日誌ブログ上 me | コメント(0) PHP 5.5の新機能 最近ぜんぜん注視してなかったけど、センス… 開拓日誌ブログ上 me | コメント(0)
完全に新規の案件というのは本当に少ないので、実践できることはほぼない理想論ですが、私の理想とするテーブル構造と命名法です。 まずは、サロゲートキーについて サロゲートキーというのは業務上意味のないキーのことです。 例えば、生徒テーブルは、年次・クラスID・生徒番号で一意になるとしましょう。 この「年次・クラスID・生徒番号」の複合キーを主キーとせずに、システム側で採番した一意な値を主キーとすることをサロゲートキーといいます。 「年次・クラスID・生徒番号」はナチュラルキーといいます。 基本は全テーブルをサロゲートキーにする方が効率的です。 サロゲートキーを使わない例外 私なりの基準は関係テーブルの場合、他に情報がない場合サロゲートキーは使いません。 例えば ■ 生徒テーブル ID 年次 クラスID 生徒番号 名前 生年月日 …… ■ 科目マスタ ID 名前 …… ■ 履修マスタ（サロゲート
数値を文字型で持つべきではない コメントをいただいたので。 前の記事はこちら。 http://d.hatena.ne.jp/Sikushima/20110809/1312871002 元ネタはこちら。 http://d.hatena.ne.jp/iad_otomamay/20110808/1312805917 http://d.hatena.ne.jp/iad_otomamay/20100906/1283786846 システムはそれぞれ要件が全く違う。だから、何事も一概には言えない。 しかし、はっきり言えるのは数値を文字で置き換えて保存するのは、普遍的な超バッドノウハウでしょう。これはどう考えてもあり得ん。 インサートされた時点の数値エリアの入力率が50％でそれが最終的に90％になる伸長率が高いデータだったとしても、 PCTFREE ＝ 100％ × 数値エリア割合 × 50％ としておい
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
サロゲートキーとは、そもそも何か？ ナチュラルキーとどう違うのか？ 「同じキーでも、システムの立ち位置によって、それがナチュラルキーかサロゲートキーかは変わりうる」 ・・・という示唆をどこぞからもらったので、それについて考えています。 じつは、「ICカード1枚1枚に付与される番号や、クレジットカード番号も、見方によってはサロゲートキーに近い値といえる」という指摘を受けるまで、クレジットカード番号なんて業務コードの最たるものであり、それ以外の考え方はありえないと思っていました。 自分が考えるサロゲートキーの特徴は、曖昧ながら、こんな感じです。 業務に依存せず、論理設計には出てこないキー 物理設計で作成するキー 複数キーを取りまとめることもあれば、単一キーに対応することもある しかしながら、「業務に依存しない」というのもまた、（前回書いた）程度問題です。 たとえば、次のような複数のキーについて
2. 自己紹介 MySQL/Linux周りのスペシャリスト 2006年9月から2010年8月までMySQL本家(MySQL/Sun/Oracle)で APAC/US圏のMySQLコンサルティングに従事 主な著書に「現場で使えるMySQL」「Linux-DBシステム構築/ 運用入門」「Javaデータアクセス実践講座」 DeNAでの主な役割 安定化/パフォーマンス/運用周りの中長期的な改善活動 L3サポート/運用/トラブルシューティング – 難度の高いMySQL周りの問題の根本原因の特定と解決 多くのプロジェクト支援 社内勉強会/トレーニング – MySQLやデータベース周りのベストプラクティスを社内で共有し、 技術スキルを底上げする 技術マーケティング – 国内外のカンファレンスや、技術雑誌等
先日、SPIDERストレージエンジンについて2度に渡り本ブログで紹介した（その１：Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン、その２：快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！）が、SPIDERの作者である斯波氏は、実はもう一つ驚くべきストレージエンジンを開発している。その名も、VPストレージエンジンだ。ちょっと地味な名前だが、VPとは、Vertical Partitioning（垂直パーティショニング）の略で、複数のテーブルの上にVPストレージエンジンを被せて、垂直パーティショニング（カラムごとにデータを格納する領域を分ける）を実現するというものだ。他のテーブルの上に被せるアーキテクチャをとっているという点では、VPとSPIDERの発想は同じである。以下は、VPストレージエンジンの動作
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く