タグ

DBに関するhokorobiのブックマーク (25)

  • @nippondanji 氏の「データベース設計徹底指南!!」は神プレゼン!脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件! - #garagekidztweetz


    1SQL 3 DB  () @nippondanji  DB  RDBRDBRDB使
    @nippondanji 氏の「データベース設計徹底指南!!」は神プレゼン!脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件! - #garagekidztweetz
    hokorobi
    hokorobi 2013/12/01
     使    

    DB

  • Data Models

    Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves

    Data Models
    hokorobi
    hokorobi 2012/11/07
  • Clojureの作者が作ったデータベースDatomicが凄い


    ClojureRich HickeyClojure HackerDatomic()10  Datomic  2014/1/20 使 Append-only 
    hokorobi
    hokorobi 2012/03/11
  • サロゲートキーは強制されるべきものではない - 設計者の発言

    複合主キーに代えてサロゲートキー(単独主キーの代替キー)を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する(あるいはサロゲートキーを導入しないと開発しにくい)開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら

    サロゲートキーは強制されるべきものではない - 設計者の発言
    hokorobi
    hokorobi 2012/01/31
  • カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC engineers' blog


    4tech.kayac  kyo_ago(tech.kayac) ! !  ! )     
    カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC engineers' blog
  • グーグル、「Google Cloud SQL」を発表。Google App EngineにMySQLをベースにしたリレーショナルDBを追加


    Google Cloud SQLGoogle Labs Google Cloud SQL By offering the capabilities of a MySQL database, the service enables you to easily move your data, applications, and services into and out of the cloud.  To ensure that your critical applications and services are always running, Google Cloud SQL replicates data to
    グーグル、「Google Cloud SQL」を発表。Google App EngineにMySQLをベースにしたリレーショナルDBを追加
  • 作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな


      -   -    -    UI使 
    作るプログラムの機能や性能で勝負したい。そうだ、データベースを勉強しよう - きしだのはてな
  • 削除フラグのはなし

    Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo

    削除フラグのはなし
    hokorobi
    hokorobi 2011/08/10
    ON DELETE CASCADE とか知らなかった。安易に TRIGGER 使っちゃってる気がするな。
  • MongoDBを半年運用してみた(のフォロー) - matsukaz's blog


    LTMongoDBMongoDB使  Mongo DB View more presentations from Masakazu Matsushita 7mongosmongodSocketWeb SocketWebJavaMongoDBJava // Shard1, Shard2, Shard3PRIMARYmong
    MongoDBを半年運用してみた(のフォロー) - matsukaz's blog
    hokorobi
    hokorobi 2011/07/30
  • 主キーのナチュラル⇔サロゲート問題 - b6note


      http://d.hatena.ne.jp/torazuka/20110713/pk  id:torazuka   http://b.hatena.ne.jp/akitsukada/20110715#bookmark-50842882 /100    ID
    主キーのナチュラル⇔サロゲート問題 - b6note
    hokorobi
    hokorobi 2011/07/17
  • 複合主キーを避けるべき理由 - 虎塚


         調#  2011/07/25 
    複合主キーを避けるべき理由 - 虎塚
    hokorobi
    hokorobi 2011/07/17
    データを部分的に本番環境から検証環境へコピーしたいような場合、サロゲートキーを使っていると本当に移したいデータに関連するデータも移さないといけないから大変かな? 既存のデータとの整合性も気にしないと。
  • サロゲートキーと複合主キー | DBFlute

    一方で、Webサービス系などで論理設計と物理設計をもう一緒くたにやっていくような場合は、 正規化の論理に目の前にあるサロゲートキーを含めないようにすることが大切で、モデリングはナチュラルキーを基軸に考えていくとよいでしょう。 サロゲートキー (代理キー) サロゲートキー + (複合)ユニーク制約 ナチュラルキーをPKにせず、例えば連番となるようなカラムを用意して、それをPKにします。 これがサロゲートキーと言われるものですが、ナチュラルキーには別途ユニーク制約を付与する というのを忘れてはいけません。 ここでは、ナチュラルキーにユニーク制約を付けずにサロゲートキーだけを導入する方式は、業務的・実装的に意味はないと考え、ここでは取り扱いません。 議論の対象にすらしません。ユニーク制約を付けることで業務的なユニーク性を保ちつつサロゲートキーの恩恵を得ることができ、同時にナチュラルキーを明示する

    hokorobi
    hokorobi 2011/07/17
    サロゲートキーの恩恵は実感しないとわからなそう。そういえば、前回のシステム変更で、すべて複合キーだった状態から一部サロゲートキーへ変更されていたな~。
  • データベース設計で派生関係は難しい - プログラマの思索


    @t_wada MySQLDB    Twitter / Takuto Wada: "" /  http://htn.to/PzrnbR 1 SNS  2 (DOA)(
    データベース設計で派生関係は難しい - プログラマの思索
    hokorobi
    hokorobi 2011/01/18
    駄目だ理解できない。
  • ソーシャルゲームのためのデータベース設計

    ・データベース的な観点でのソーシャルゲームの特徴 ・データモデル ・ソーシャルゲームに従来型RDBMSを使うべきか、�流行りのNoSQLで行くべきか ・負荷対策 (アーキテクチャ面) ・負荷対策 (ツール面) ・インフラエンジニアのキャリアについて

    ソーシャルゲームのためのデータベース設計
  • DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して

    データベースには,「トランザクション分離レベル」というものがある。 以下では,それが なぜ必要なのか? デフォルトのレベルでは,どうして駄目なのか? PostgreSQLでは,どうやってレベルを変更・確認するのか? などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは: 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか,のレベル。 ANSI規格では,4つのレベルがある。 READ UNCOMMITTED (一番低い) READ COMMITTED REPEATABLE READ SERIALIZABLE(一番高い) 徹底比較!! PostgreSQL vs MySQL 第3回:トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく

    DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して
    hokorobi
    hokorobi 2011/01/05
    トランザクション分離レベルは初耳だった。
  • データベースの差分表示·DiffKit MOONGIFT


    DiffKit/CSV [/s2If] DiffKitJava DiffKit使 DiffKitDiffJDBCCSVCSV
    hokorobi
    hokorobi 2010/11/27
    DDLの適用を忘れているという状況が見つけやすそう。そんなことにならないように自動化するべきなんだろうけれど。
  • Java製のデータベースマネージャ·Druid MOONGIFT


    DruidSQL [/s2If] DruidJavaNoSQLO/R  GUISQL便DruidDruid E-R 
    hokorobi
    hokorobi 2010/11/27
    ちょっと触ってみたけど、使いどころはどこだろう?
  • DBセキュリティの第2弾、アクセス・コントロールと権限管理

    データベースのアクセス・コントロール セキュリティ対策の基は、アクセス・コントロール(アクセス制御)と、ユーザーの権限管理です。データベースには、一般によく知られている公開情報に加えて、個人情報や機密情報も格納されています。情報資産を保護するために、「どの情報に誰がアクセスできるのか」をコントロールすることが、当たり前のこととして認知されています。 データベースに対するアクセス制御の形態には、適用する範囲に応じて、いくつかあります。以下のように分類できます。 アプリケーション側で実装する、データベースに対するアクセス制御 データベース側で実装する、データベースに対するアクセス制御 データベースに格納されている、表へのアクセス制御 表の中の、特定の行や列に対するアクセス制御 データベース自身に対するアクセス制御は、アプリケーション側で機能を実装したり、データベース管理者がポリシー設定を行い

  • グリーの大規模分散ストレージ戦略(nanofs) Vol.2 | GREE Engineering

    はじめに グリー株式会社でエンジニアをしておりますkgwsと申します。 今回は、前回に引き続き分散ストレージ(nanofs)のHTTPメソッド毎の処理を紹介させていただければと思います。 nanofsは5つのHTTPメソッド(GET、PUT、DELETE、HEAD、MKCOL)をサポートしております。今回は主なGET、PUT、DELETEの3つについてご説明させていただきます。 まずは構成のおさらい nanofsは、主に3つのプロセスで構成されております。 nanofsd(dispatcher) アプリケーションサーバからリクエストを受け取り実際に保存されているnanofsnに振り分ける 5つのHTTPメソッドをサポートしている(GET、PUT、DELETE、HEAD、MKCOL) データベース(KVS)に保存したデータの情報を送る queueに処理の指示を送る nanofsw(worke

    グリーの大規模分散ストレージ戦略(nanofs) Vol.2 | GREE Engineering
  • CassandraとHBaseの比較して入門するNoSQL

    ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD

    CassandraとHBaseの比較して入門するNoSQL