【イチから理解するサーバーレスアプリ開発】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス 20190905版2019/09/05 に開催された AWS のイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。 ・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由 ・RDB と DynamoDB の設計プロセス・考え方の対比・明文化 ・実例に沿った DynamoDB の設計プロセス解説とサンプル例題 などを含みます。Read less
一人トランザクション技術のカレンダー | Advent Calendar 2016 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
正しいデータは正しい設計に宿る - そーだいなるらくがき帳
って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま
悲観的排他制御と楽観的排他制御－同時更新の対処方法 | アイビースター
プログラムの処理方法で一つのデータを複数人で更新したときのトラブル防止として、「悲観的排他制御」と「楽観的排他制御」があります。下記にその解説用の図を書いてみます。 複数人による同時更新トラブル データベースのあるデータを複数人で更新することがあります。その更新を同時に行った場合どのようなことが起こるでしょう。 例えばユーザーAがデータベース（DB）内のIDが12のデータを更新しようとします。既存のデータを取得し、ある項目を「犬」と入力しました。この時点ではDBのデータは変わっていません。 ユーザーAがデータを取得した後にユーザーBが同じIDが12のデータを取得し、同じ項目を「猫」と入力しまし、ユーザーAよりも早くDBを更新しました。DBのID：12のデータは「猫」が入っています。 ユーザーBがDBのデータを更新した後、ユーザーAがデータを更新するとDBのID：12のデータは「犬」に変わり
NoSQL Databases: a Survey and Decision Guidance
(At the bottom of this page, you find a BibTeX reference to cite this article.) Together with our colleagues at the University of Hamburg, we — that is Felix Gessert, Wolfram Wingerath, Steffen Friedrich and Norbert Ritter — presented an overview over the NoSQL landscape at SummerSOC’16 last month. Here is the written gist. We give our best to convey the condensed NoSQL knowledge we gathered build
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
A5:SQL Mk-2でER図を描こう！！
A5:SQL Mk-2を使ってER図を描こう！！ このページでは ER図の簡単な説明と A5:SQL Mk-2 からER図を描く手順を示します。 ER図とは ER図とはコンピュータシステムを設計するときに、現実社会でのシステム化対象を「モデル化」するために用いる図です。 一そろいのデータの集まりをエンティティ(Entity)、エンティティ同士の結びつきをリレーション(Relation)と呼んで図にします。これがER図（Entity-Relation Diagram）と呼ばれるゆえんです。 データベース設計では特に、エンティティをテーブル、リレーションを参照整合性制約として図を描くことが多いですが、本来ER図は現実社会をモデル化したものであることを心にとめておいてください。 ER図の記号 エンティティとリレーション エンティティの記号 エンティティは箱の中にデータの名前を列挙して表します。
SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
昨日のエントリ「SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる（「'OR'1」）ことを示しましたが、@masa141421356さんと、やまざきさん（お二人とも拙著のレビュアーです）から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います（id側に「'OR」, pwd側に「>' 」で6文字）。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
MySQL のNULL ではまったことあれこれ - LukeSilvia’s diary
MySQL に限らず、SQL のNULL の仕様には何回か「えっ」と驚くことがあったのでメモしておこうと思います。5.1 版の日本語マニュアルがなかったものについては、4.1 のマニュアルを参照しました。 そもそもNULL は何を意味するか NULL は未定義または、不明を意味する。「電話番号を持たない」ということを表現する場合は、NULL ではなく、空の文字列を使う。 NULL 値というものを SQL 初心者はよく混乱します。SQL 初心者は、多くの場合、NULL が空文字 "" と同じであると考えてしまいます。これは違います。たとえば、以下のステートメントは完全に別のものです。 mysql> INSERT INTO my_table (phone) VALUES (NULL); mysql> INSERT INTO my_table (phone) VALUES (""); どちらのス
「絵で見てわかるITインフラの仕組み」という本を書きました - ablog
共著で絵で見てわかるITインフラの仕組み (DB SELECTION)という本を書きました。 絵で見てわかるITインフラの仕組み (DB SELECTION) 作者: 山崎泰史,三縄慶子,畔勝洋平,佐藤貴彦,小田圭二出版社/メーカー: 翔泳社発売日: 2012/09/19メディア: 単行本（ソフトカバー）購入: 11人 クリック: 204回この商品を含むブログ (7件) を見る 内容 初心者向けの本です。ITインフラにおける、普遍的な概念や仕組みを絵を使って説明しています。インフラエンジニア向けの本ですが、アプリケーションを設計・開発しているエンジニアやプログラマの方にも役に立つ本ではないかと思います。システムアーキテクチャの設計、パフォーマンスチューニング、トラブルシューティングではOS、ハードウェア、ネットワークなどの知識も必要とされます。 流れの速いIT業界では次々に新しい技術が登場
Google Sites
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
インデックスの基礎知識
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴を持つデータの設計
RDB THE Right Way - builderscon 2018/ RDB_THE_Right_Way
MySQLテーブル設計入門
https://developer.oracle.com/jp/technical-resources/articles/secret-of-oracle-site.html
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
サービス終了のお知らせ
削除フラグのはなし
