タグ

DatabaseとRDBに関するslay-tのブックマーク (6)

  • データベース設計の際に気をつけていること - 食べチョク開発者ブログ

    皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ!”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

    データベース設計の際に気をつけていること - 食べチョク開発者ブログ
  • 書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL

    来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり来どの

    書籍出版のお知らせ:理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL
  • Validation nightで発表しました。

    RDBにおけるバリデーションをリレーショナルモデルから考える」という、なんとも捻りも面白みもないタイトルである。だが、RDBとValidationという2つが相容れないものだということを知っている人には、割と琴線に触れる話かも知れない。 正直なところ、現在私はデータベースエンジニア一直線なので、アプリケーション開発におけるセキュリティというのは門外漢であると言って差し支えない。しかもイベントにはあの徳丸浩氏(バリバリの職)も発表されるというではないか!!順番的には徳丸氏の次に話したのだが、徳丸氏はSQLインジェクションの実演までするというガチっぷりである。 「場を白けさせてしまうのではないか・・・」 「ガチの人から特大のマサカリが飛んでくるのでは・・・」 そんな想いを脳裏に抱きつつ発表に望んだのであった。 今回の持ち時間は20分と短めであったが、あまりたくさん話したいネタも無かったので

    Validation nightで発表しました。
  • あなたが知らない リレーショナルモデル

    1. あなたが知らない リレーショナルモデル @dbtech showcase tokoy 2014 奥野 幹也 Twitter: @nippondanji mikiya (dot) okuno (at) gmail (dot) com 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● ブログ 今日は個人として 参加しています。 – 漢のコンピュータ道 – http://nippondanji.blogspot.com/

    あなたが知らない リレーショナルモデル
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
  • データベース設計徹底指南

    DBエンジニアのための技術勉強会(第3回)で使用した資料です。主にリレーショナルモデルと正規化について解説しています。リレーショナルモデルの限界について正しく認識してこそ、リレーショナルモデルを理解したと言えると思います。

    データベース設計徹底指南
  • 1