論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
データがどのように更新されてきたのか追跡する - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 みなさんは、異常なデータを見つけたが、どうしてそのような状態になったのか追跡できず困ったという経験はないでしょうか。 今回は、そんなときにクックパッドで利用されているAuditログについてご紹介します。 Auditログとは クックパッドでのAuditログは特定のデータレコードに対して発生したイベントをコンテキストとともに記録するものです。 一般的に監査ログ、証跡ログといったものがありますが、それらとは多少異なっています。 ここでのイベントとは、あるデータレコードが 作成された 更新・変更された 削除された といったものです。またそれ以外にもログインした、ログアウトした、セキュアな情報が閲覧された、といったイベントも含まれています。 コンテキストは以下のようなものを記録します。 いつ どこで 処理が行われたホスト 何が イベント 何を 対象データの情報 スキー
DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
筑波大学でデータベースの話をしてきました - kuenishi's blog
筑波大学の川島先生に呼ばれて木、金と情報システム特別講義Dというやつに参加してきた。こんなことになるとは思っていなかったが、あろうことか講師側で呼ばれてしまい、思えば遠くへ来たものだと感慨深い。フリは「RiakとNoSQLの話をしてもらえたら」という非常に自由度の高い内容なので、せっかくなので僕の知っていることを全部詰め込んで話してやろうと思ったら10分延長してさらにスライド10枚分くらいを消化不良で終了という、みっともない感じになってしまった。かなり端折ってポイントだけ説明したので流れが分からず苦労した方も多いと思うが、まあ僕の性格なので許してほしい。データベースの講義をひと通り終えた院生レベルを想定してスライドを作ったので、もしかすると、わりと難しかったり分かりにくかったりするかもしれないので、わからないことがあったら適当に質問してください。 言いたかったことの流れを僕なりにまとめると
InfoQ: Web開発者が知っておくべき八つの分離レベル
原文(投稿日：2009/3/15)へのリンク ACID特性はデータベース論の基礎の一つです。ACIDではデータベースの信頼性を保つために必要とされる4つの属性を定義しています。原子性(Atomicity)、一貫性(Consistency)、分離性(Isolation)、そして永続性(Durability)です。4つの属性はいずれも重要ですが、とりわけ分離性については最も柔軟に解釈されています。ほとんどのデータベースがいくつかの分離レベルを選択できるようにしていますし、最近は多くのライブラリがより極め細やかな分離レベルを作成するレイヤを追加しています。このように広範囲の分離レベルが存在している主な原因は、緩い分離レベルによって拡張性や性能が数桁のオーダーで異なることにつながるからである。 シリアライズ可能というのは最も古典的で高い分離レベルであり、一般的に使うことが出来るもので、多くの人がそ
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
「名ばかりのプロには負けない！」!)!)がんばる中小企業のDB達人たち
国内に約500万社ある中堅中小企業。その中でも小規模な企業の多くには「情報システム部」と呼ばれる部署はないし，システム構築や運用を担当する専任社員がいない場合がほとんどだ。では，いったい誰がどうやって生産管理や受発注管理システムを導入しているのだろうか――。 「外部のシステム専門業者に委託するしか道はない。素人がデータベースを作るなどは論外だ」。記者自身，中小企業のIT活用誌「日経IT21」を担当する前までは，こう確信していた。しかし，それは間違いだった。中小企業のデータベース事情を取材してみると，営業や総務，工場で働いている現場の社員が，パッケージ・ソフト顔負けのデータベースを“自作”し，全社で活用しているケースが続々と出てくるのだ。 システム業者への強い不信感から“自作”を選ぶ パソコンの普及やマニュアル書籍の充実など，専門家でなくとも手軽にデータベースを作れる環境が整ってきたことは大
最近のLinuxで有効になっているI/Oバリア機能と、RDBへの影響 | Unofficial DB2 BLOG
比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。 I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序（物理ディスクに反映される順番）をまもらせる仕組みといえます。 ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。 そもそも、急な電源断でもファイルシステムの不整合が起こ
トランザクションは再利用の敵である
釣りっぽいタイトル。「RDBのトランザクションが絡むとアプリケーション側のプログラムが書きにくくなる」という話です。 もちろんですが、RDBのトランザクション機能は偉大であり、Webアプリケーションでも意識して使わなければならず、「トランザクションなんて使うな」と言いたいわけではありません。 合成できない関数 PHPで素のPDOから考えます。たとえば、以下の関数に問題はあるでしょうか？ <?php /* * 古いデータをアーカイブテーブルに移す関数のイメージ */ function moveDataToArchive(PDO $db) { $db->beginTransaction(); try { $db->exec(' INSERT INTO archives SELECT * FROM data WHERE published < CURRENT_DATE '); $db->exec
みんなビックデータビックデータって言ってるけど 名寄せとかどうしてんの？
自由診療クリニック向けのオールインワンSaaS「medicalforce」、警備事業者向けオールインワンSaaS「警備フォース」を提供する株式会社メディカルフォース。フルスクラッチでの開発を実現させるスクラムの構築をまとめました Developer eXperience Day 2024 株式会社メディカルフォース CTO 畠中 翔一（@punk_punx）登壇スライド
よくある質問 - Amazon RDS | AWS
Amazon Relational Database Service (Amazon RDS) は、クラウド内でリレーショナルデータベースのセットアップ、運用、およびスケーリングを簡単に行うことのできるマネージド型サービスです。これにより、時間のかかるデータベース管理作業をお客様の代わりに実行して、お客様を管理業務から解放し、アプリケーションとビジネスに集中させることができます。このサービスはコスト効率もよく、データベース容量の変更にも柔軟に対応します。 Amazon RDS では、使い慣れた PostgreSQL 用 RDS、MySQL 用 RDS、MariaDB 用 RDS、SQL Server 用 RDS、Oracle 用 RDS、または Db2 データベース用の RDS の機能にアクセスできます。つまり、既存のデータベースで既に使用しているコード、アプリケーション、およびツールは、
wiperdog.org
wiperdog.org 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
「新機能」「廃止機能」「サポート状況」から見たユーザーにとってのOracle Database 12c
「新機能」「廃止機能」「サポート状況」から見たユーザーにとってのOracle Database 12c：ユーザー目線でチェック！ Oracle Database 12cの知りたいところ（1）（1/3 ページ） Oracle Database導入を実施ならびに支援するサービスプロバイダという筆者の立場から、ユーザーにとっての新バージョンの意義を考えながら、新機能や廃止された機能などを紹介します。 2009年のOracle Database 11g R2のリリースから約4年が過ぎ、Oracle Databaseの最新バージョンOracle Database 12c R1がリリースされました。本連載では、Oracle Database 12c R1の主要な新機能をユーザーの立場に立って実際に使用、評価し、新機能の活用方法や注意点を紹介します。 第1弾となる本記事では、Oracle Databas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より深く知るオプティマイザとそのチューニング
データベース技術の羅針盤
RedshiftはDWHだけじゃない
