【DB概論】DBMSに求められるもの(1)排他制御とACID属性:できるエンジニアになる! ちょい上DB術・基礎編(2) デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。
![【DB概論】DBMSに求められるもの(1)排他制御とACID属性](https://cdn-ak-scissors.b.st-hatena.com/image/square/d155058b945bd4af56b925ef7a1eab9a5d49bb62/height=288;version=1;width=512/https%3A%2F%2Fimage.itmedia.co.jp%2Fait%2Farticles%2F1106%2F24%2Fr502-01.gif)
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
かつては非常に高価なもので、手軽に導入できないという印象のあったデータベースですが、現在では、PostgreSQLやMySQL、Firebirdなどといったオープンソースのデータベースが商用のものに引けを取らない機能、性能を備えるようになり、それほど規模の大きくないWebアプリケーションであっても、あたりまえのようにデータベースが使用されるようになりました。 本特集では、Webアプリケーションを初めて開発するという方に向けて、データベース設計の基本について説明していきます。なお、一言にデータベースといってもいろいろなものがありますが、いわゆるテーブルによってデータを管理するリレーショナルデータベースを対象とします。 今回は、データベース設計の全体的な流れについて説明します。 データベース設計とは、データベースによってデータを管理できるように、現実の世界を抽象化してデータモデルを作成していく
排他制御とは 共有資源(データやファイル)に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源(データやファイル)にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック(楽観的排他制御)と悲観ロック(悲観的排他制御)を紹介する。 楽観ロック(楽観的排他制御) 楽観ロックとは、めったなことでは他者との同時更新は起きないであろう、という楽観的な前提の排他制御。データそのものに対してロックは行わずに、更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する方式。楽観ロックを使用
こんにちは。検索サービス開発4チームでメッセージアプリのLINEのiPhoneアプリ開発を 担当している金泰敬(キム テギョン)です。 今回説明させて頂きたい主題はLINEのモデル側を支えているCore Dataです。 Core Dataは、MacOS XのベースFrameworkであるCocoaのMVC構造のうち、 Model側を担当しているFrameworkです。 Core Dataを利用するとデータモデルの設計、オブジェクトのデータの読み取り、書き込み、管理などを簡単に行うことができます。 現在、LINEではCore Dataを利用してメッセージ、トーク、グループ、ユーザーなどを管理しています。 例えば、相手のメッセージが到着するとまずコアのデータからSqliteDBに格納します。 そして保存されたメッセージに関連しているトークでも更新が行われます。 もしそのメッセージが
データベース設計はいつ、何をポイントに行うか:ゼロからのデータモデリング入門(4)(1/3 ページ) 前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。 どの段階でどう設計すればいいのか 前回、データベース設計は自社のビジネス活動を理解している自社内の人間がやるべきであり、情報システム部門の存在意義を高めるために必要な技法であるとお伝えしました。しかし、システムの外部委託が多いというのもまた事実です。 筆者の職場では、お客様からデータモデリングに関するご相談をいただく際、最初に「貴社のデータモデルを拝見させてください」というお願いをします。システム開発を外部委託しているケースでは多くの場合、形として残っているのは「物理データモデル」で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く