履歴を持つデータの設計酔いどれ設計ナイト2019の発表資料です。
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
棋士系統図｜棋士データベース｜日本将棋連盟
棋士系統図は棋士の師弟関係をまとめています。 詳細は下記の画像をクリックしてPDFファイルにてご覧ください。
苗字がNullの社員がうちのとこの社員管理用のシステムをぶっこわしたんだがどうすればいい？
flex - How can I pass the string "Null" through WSDL (SOAP) from AS3 to ColdFusion web service without receiving a "missing parameter error"? - Stack Overflow stackoverflowで、 「"Null"という文字列をAS3のWSDL(SOAP)からColdFusion Webサービスに、"missing parameter error"というエラーを出さずに渡すにはどうすればいい？」 という質問が注目を集めていた。 はて、この問題はどこかで見た気がする。 xkcd: Exploits of a Mom 「もしもし、あなたの息子さんの学校です。うちの学校がコンピューターシステムのトラブルに見舞われまして」 「あらまぁ、うちの子が何か
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ - エンジニアHub｜Webエンジニアのキャリアを考える！
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
クラウドで苦労が増えるデータベースの乗り換え
データベース（DB）が企業システムの中核機構であることに異を唱える人はいないだろう。そして、技術者ならオンプレミス（自社所有）環境でDBを“乗り換え”る作業がクリック一つで済むような簡単なことではないとも十分承知していると思う。記者はクラウドへのシステム移行事例を取材するケースが多く、DB移行でも苦労話をよく聞く。 そもそもオンプレミス環境からクラウドにデータベースを移行するだけでも容易ではない。土木や建築、しゅんせつ事業などを手掛ける小柳建設は2016年9月、オンプレミス環境の基幹系システムを米マイクロソフトが提供するIaaS（インフラストラクチャー・アズ・ア・サービス）、PaaS（プラットフォーム・アズ・ア・サービス）関連のパブリッククラウドサービスである「Microsoft Azure」上に全面移行し、本格運用を開始した。 移行で最初の課題となったのが、Azureの仮想マシンである「
複合インデックスの正しい列の順序
データベースは、プライマリキーに対して自動的にインデックスを作成しますが、キーが複数の列からなる時は、さらに手動で調整をする 余地があります。この場合、データベースはプライマリキーの全ての列にいわゆる 連結インデックス(あるいはマルチカラム インデックス、複合インデックス)を作成します。 複合インデックスの列の順番は、インデックスの使い勝手に大きな影響を及ぼすので、注意して決定する必要があります。 例として、企業が合併した場合を考えてみましょう。他の会社の社員が 加わったので、EMPLOYEESテーブルが10倍の大きさになったと しましょう。ここで問題が発生します。EMPLOYEE_IDが、 それぞれの会社で一意になっていなかったのです。子会社IDのような追加の識別子で、プライマリキーを拡張する必要があります。このため、プライマリ キーは、以前からのEMPLOYEE_IDに加えて、一意性を
商品コードを主キーにするべきではない理由
リレーショナルデータベースのテーブルの主キーの設計については「ユニークになる項目だから必ず主キーにしないと行けない」というわけではなく、多くのDB設計者の間でも - ID派（あえて別に自動採番のIDを付ける） - コード派（ユニークになるものは出来るだけ主キーとする） の2つに分かれる様だ。特に近年はRuby on Railsに代表される様に数値型の単一キーの存在を前提として作られているFrameworkが増えて来た事もあって、ID派の存在感が増しているらしい。 それぞれメリット・デメリットがあってどちらがいいのかはケースバイケースになるのかも知れないが、自分の場合はこれまでの業務システム開発の経験から、どちらかと言うと自動採番のIDを使う方がメリットが多いのではないかと思っている。やっぱりなんだかんだ言っても、「どうしてもこのマスターのコードを変えたいんだけど」と言われるケースが何度かあ
ORDER BYとGROUP BYがSQLのパフォーマンスに与える影響
ソートは、非常にリソースを消費する処理です。かなりのCPU時間を必要としますが、問題の核心は、データベースが結果を 一次的にバッファしておかなくてはならないことです。ソート処理では、全ての入力を終えなければ、結果を出力することができません。ソート処理は、 パイプラインのようには実行できないのです。これは、データセットが大きい時に、問題になります。 インデックスされたデータはインデックスの順番に並んでいるという原則は、第1章1で既に説明しました。 そこから、インデックスはデータを既に並べ替えられた形で保存するためのものであるとも言えます。実際にインデックスは、order by句にインデックスの定義があるかのように並べ替えられます。 そのため、order by句を満たしつつソート処理を避けるために インデックスが使えるというのは、自然な考え方と言えるでしょう。 皮肉な事に、INDEX RANG
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
第8回 SQLにおける論理演算～なぜ真理を隠すのか～ （1）各DBの真理値型のサポート | gihyo.jp
はじめに 真理値と論理演算の重要性 プログラマやSEのみなさんは、真理値（真偽値）というものをご存じのことと思います。ほとんどの言語が持っている基本的なデータ型で、数学者George Booleの名前にちなんで「BOOL型」とか「BOOLEAN型」とも呼ばれています。コンピュータを利用していると、BOOLEAN型が持つtrue（真）とfalse（偽）の2つの値と、NOT、AND、ORという3つの演算子だけから成るシンプルな演算（論理演算）を行うことが多くあります。これはプログラミング言語だけでなく、コンピュータの回路の基礎にもなっている演算です。 SQLにおける真理値と論理演算 SQLにも、真理値と論理演算が存在します。存在するどころか、WHERE句やHAVING句は、それ全体が論理演算のカタマリです。だから真理値はSQLの根幹をなす重要な要素と言っていいのですが、それにもかかわらず、SQ
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースオブジェクトの命名規約 - Qiita
Webエンジニアに知ってほしいRDBアンチパターン
