ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録される。 一般的にusersにカラムを増やしたいような内容はここに登録する。 なぜusersにカラムを増やさないのか？ それはusers
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
業務システム設計に関する本 - プログラマの思索
業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (
「ユーザーに対する暴挙を許せない」、日本HPがOracleからのDB移行戦略を発表
日本ヒューレット・パッカード（日本HP）は2011年4月26日、データベースに関する新戦略の発表会を開催した。新戦略では「データベース ロックリリース」をキーワードに、特定のベンダーの製品にロックインされがちなデータベース環境を、他のベンダー製品上に移行しやすくするサービスを提供する。これにより、データベースベンダーに対するユーザーの価格交渉力を高めることを狙いとする。 日本HP エンタープライズサーバー・ストレージ・ネットワーク事業統括の杉原博茂執行役員（写真1）は、新戦略を発表した背景として「ユーザーのコストを削減するには、データベースソフトに支払うライセンス費用を見直すことが必須になっている」ことを指摘する。日本HPの試算で2005年の同一性能モデルと現在のコスト構成を比べてみると、ハードウエア費用は20分の1以下になっているのに対し、データベースは30％強ほど下がっているに過ぎない
Oracle
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
PostgreSQL で 24:00 と 0:00 を扱う - ronSpace
問題の趣旨を理解できていないかもしれませんが。 これができないから、いつまでたっても、Date型とか使わずにcharやnumberな日付時刻カラムがなくならないんだよな。 BusinessDateTime型 - L'eclat des jours (2009-03-06) 夜勤帯が存在するような業務の場合、「当日の24:00」と「翌日の0:00」を区別したい、という話は出てきますね。 日付と時刻を分割するしかないんじゃないですかねえ。 PostgreSQL ですと、こんな感じになります。 create table t_event( ev_id serial, ev_date date, ev_interval interval, ev_str varchar(10), primary key (ev_id) ); insert into t_event( ev_date, ev_inter
sqlite: SQLite データベースと会話するプログラム
sqlite: SQLite データベースを管理するプログラム (This page was last modified on 2003/06/29 16:11:13 UTC) SQLite ライブラリには sqlite というシンプルなコマンドライン ユーティリティが含まれます。これを使うと、ユーザは手作業で SQLite データベースに接続して SQL コマンドを実行できます。この文書では sqlite の使い方に関する概略を紹介しています。 起動する sqlite を起動するには単に "sqlite" とタイプし、その後ろに SQLite データベースを保持するファイル名を付けます。ファイルが存在 しない場合は、自動的に新しく作られます。起動後 sqlite プログラムは、SQL をタイプするためのプロンプトを表示します。 SQL ステートメント（終了はセミコロン）をタイプし、 "E
UNIX データベース入門 稚内北星学園短期大学 丸山不二夫
稚内北星学園短期大学 経営情報学科 丸山不二夫 1994年 8月 5日 Contents 序章 リレーショナル・データベース概観 リレーショナル・データベースとは データベースは情報をどのように組織しているか 情報のいれものとしての「テーブル」 リレーショナルとは すべての関係は、テーブルである 関係演算 リレーショナル・データベース上の標準言語ＳＱＬ 本書でのSQLの扱い方の特徴 Select selectの基本形 テーブルから指定した項目を抜き出す select 見出しの変更の２つの方法 行内への文字列の表示 項目リスト中の式 from 句 テーブルの積 where句 検索条件の指定 論理演算 リスト null値 文字列の比較 likeとワイルドカード ジョイン テーブルの結合 項目名の修飾 三つのテーブルのジョイン テーブル名のエイリアス（別名） 自己自身とのジョイン サブ・クェリー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
xRef - Database
Mobage を支える Ruby の技術 ~ 複数DB編 ~ : sonots:blog
http://www.sra.co.jp/people/t-ishii/
SQLite入門
月に遊ぶ » SQLiteの使いかた
サービス終了のお知らせ