アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
はじめての Elasticsearch - Qiita
この記事は全文検索エンジン「Elasticsearch」の入門チュートリアルです。 Elasticsearch とは Elasticsearch は Elastic 社が開発しているオープンソースの全文検索エンジンです。 大量のドキュメントから目的の単語を含むドキュメントを高速に抽出することができます。 Elasticsearch では RESTful インターフェースを使って操作しますが、「Elasticsearch SQL」を使って SQL 文でクエリを記述することもできます。 Oracle や MySQL などのリレーショナルデータベースに慣れている人にとっては、最初はとっつきにくいと感じるかもしれません。 しかし、Elasticsearch の API はとてもシンプルなので、心配しなくても大丈夫です。 Elastic Stack とは Elastic Stack は Elasti
システムで「性別」の情報を扱う前に知っておくべきこと - 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が登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
"「単独主キー主義」の是非を問う" 勉強会で得られた知見 - ジャスミンソフト日記
さった6月28日に超高速開発コミュニティ&IT勉強宴会共催で開催された件名の勉強会の報告です。 https://benkyoenkai.connpass.com/event/58333/ すでにいくつものブログがアップされています。私が教えてもらったページを紹介します。 たなかこういちの開発ノート - サロゲート単独主キー vs 複合主キーの話、予習編 http://tanakakoichi9230.hatenablog.com/entry/2491274126 たなかこういちの開発ノート - サロゲート単独主キー vs 複合主キーの話、復習編 http://tanakakoichi9230.hatenablog.com/entry/0631240514 システム開発の本質とは～単独主キー主義 VS 複合主キー許容派～ https://www.talon.jp/column/past_20
MastodonのER図を生成してみた · hnakamur's blog
2017-04-24 はじめに voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications を使って tootsuite/mastodon: A GNU Social-compatible microblogging server のER図を生成してみました、というだけの記事です。 Relax Ruby version requirement (#1901) · tootsuite/mastodon@0611209 のコミットに対して 生成したPDFが mastodon-er-diagram.pdf です。 たぶん今後更新しないので新しいER図が欲しい方は自分で生成してください。 生成手順 生成時にデータベースにアクセスするので、mastodonのソースを git clone しただけで
ER図レビューの３つのポイント - 設計者の発言
前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。 ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。 ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。 そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意
Spring Bootでデータベースを扱う - かずきのBlog@hatena
h2データベースでさくっと試してみました。 pom.xmlに以下の記述を追加。今回はh2なのでh2のjdbcドライバを追加してます。SQL ServerならSQL ServerのJDBCドライバを追加するといいと思います。 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> </dependency> そして、JPAのリポジトリを有効にするためAppクラスにEnableJpaRepositoriesアノ
政府統計の総合窓口 GL01010101
統計データを探す すべて 分野から探す国土・気象人口・世帯労働・賃金農林水産業鉱工業商業・サービス業企業・家計・経済住宅・土地・建設エネルギー・水運輸・観光情報通信・科学技術教育・文化・スポーツ・生活行財政司法・安全・環境社会保障・衛生国際その他 組織から探す 内閣官房人事院内閣府公正取引委員会警察庁消費者庁こども家庭庁総務省公害等調整委員会消防庁法務省外務省財務省国税庁文部科学省文化庁スポーツ庁厚生労働省中央労働委員会農林水産省林野庁水産庁経済産業省資源エネルギー庁特許庁中小企業庁国土交通省観光庁海上保安庁環境省防衛省 主要な統計から探す ５０音から探す あ い う え お か き く け こ さ し す せ そ た ち つ て と な に ぬ ね の は ひ ふ へ ほ ま み む め も や ゆ よ ら り る れ ろ わ すべて見る 分野から探す 国土・気象人口・世帯労働・賃金農林
SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現
SSDに最適化したアーキテクチャで開発中のRethinkDBはトランザクションの基本となるACID性を備えているにもかかわらず、これまでのリレーショナルデータベースと比べて優れた機能を実現しようとしているようです。同社のWebサイトで解説している内容を基に、紹介していきましょう。 まず基本的な特長として、RethinkDBはMySQLのストレージエンジンと互換性を持つデータベースエンジンで、MySQLのストレージエンジンを入れ替えることで、アプリケーションには何の変更もせずに使い始められるとのこと。 ロックフリー トランザクションを実現している一方で、ロックは発生しないとのこと。更新や削除をしようとしているデータに対しても安全に読み出しが可能。 オンラインで実行可能な管理機能 データベース利用中でも性能に影響を与えずに、バックアップ、スキーマの変更、ガベージコレクションなどを実行可能。My
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
無料で使える「住所マスターデータ」公開、表記統一や緯度経度への変換に活用可能 全国の町丁目レベル18万9540件の住所データを記録
あなたが知らない リレーショナルモデル
イミュータブルデータモデル(入門編)
DBSに必要な「暗号技術」の基礎
サービス終了のお知らせ
逆引きSQL構文集
jpn.ph