データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
RDBII_ASSISTTABLE RDBII_CODE RDBII_COLUMN RDBII_COLUMN_USAGE RDBII_COMMENT RDBII_CONSTRAINT RDBII_DATABASE RDBII_DESCRIPTION RDBII_INDEX RDBII_OBJECT RDBII_OBJECT_AUDIT RDBII_OBJECT_PRIV RDBII_OBJECT_PWD RDBII_OBJECT_SEQ RDBII_OPT RDBII_PARAMETER RDBII_PRIVILEGES RDBII_PROC RDBII_PROC_COL RDBII_ROLE RDBII_ROLE_GRANT RDBII_ROLE_PRIV RDBII_SCHEMA RDBII_SEQUENCE RDBII_TABLE RDBII_TABLE_USAGE RDBII_TF
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF（単一故障点）を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach
●既存のDB技術と一線を画すデータ検索技術を生み出す ●ゼロベースで発想しOSの基本機能に着目 ●ストップウオッチ片手に高速化を追求 ソフト開発ベンチャーのHOWSが、これまでにないデータ管理・検索技術「ISSEI」を開発した。HOWSは現在、ISSEIを次世代Web基盤技術として特許を出願している。 「ユーザー企業がデータを有効活用するためには、既存のリレーショナルデータベース（RDB）と一線を画す技術を編み出すほかないと考えた」。HOWSのCTO（最高技術責任者）である庄司渉副社長は、ISSEIを開発した思いを語る。 ユーザー企業の多くは現在、社内システムを整備し、テキストや画像、音声などさまざまな種類のデータを大量に蓄積している。その一方で「データを業務に有効活用できていない」と嘆くCIO（最高情報責任者）が多いのも事実だ。 その理由について庄司副社長は、「現在主流のRDBが限界に近
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く