not found
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
前回のエントリーは各方面で議論を引き起こしたようだが、「複合キーを許すべきかどうか」ではなく「関連をコード項目で構成すべきかどうか」の議論が目立ってしまった印象がある。筆者がもともと主張したかったことは「複合キーを許すべきかどうか。それは許される」である。つまり、その識別子項目が何と呼称されるものであっても、他の識別子項目と「複合」して識別子を構成するケースがいくらでもあるというものだ。 たとえば「商品テーブル」の識別子が何と呼ばれようが、そして「倉庫テーブル」の識別子が何と呼ばれようが、それらが複合したものを識別子とする情報のまとまりが存在し得る(「在庫テーブル」だったりする)。それに単独項目の識別子を与えるよりも、素直に商品と倉庫の識別子を複合したものを識別子として与えたほうがいいよ、というのが筆者のもともとの主張である。 では、「関連をコード項目で構成すべきかどうか」の議論はどのよう
データモデリングでは、複合キーに代わって単一項目の代理キー(サロゲートキー)を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル(基本方針)」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される(つまり、商品と倉庫の組み合わせで棚が決まる)ことになっているとする(在庫管理では典型的な業務要件だ)。この関係をデータモデルで表すとモデル1のようになる。横浜第1倉庫でA01の棚に保管されることになっている商品100の現在庫が250個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル2のようになる。 2つのモデルの形式上の違いはどこにあるのだろう。モデル1では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
JAVA を使って構築した商用サイトでは、ほぼ必須技術でもあるDBコネクションプーリング。DBコネクションプーリングを導入するメリットは、データベース操作の中でも非常に負荷の高い接続処理の隠蔽と、コネクション数の削減によるリソースの浪費回避につきる。 今回は、どうしても Perl で Oracle のコネクションプーリングをしたくて、SQL Relay の導入を検討してみた。SQL Relay オープンソースのDBコネクションプーリングサーバで、Oracle、MySQL、PostgreSQL 等々、通常利用するほとんどのデータベースに対応している。また、C/C++、Perl、PHP、Ruby、Java 等々の多言語対応も実装し、独自 API と DBI によるアクセス方法が用意されているので大変便利です。 はじめに C++ 用の汎用クラスライブラリである Rudiments をインストール
PostgreSQLに対応したコネクションプーリングサーバには、pgpoolの他にも「SQLrelay」がある。今回はpgpoolとの比較対象として、この"SQLrelay"を導入してみよう。 SQLrelayは、GPLの下で配布されているフリーソフトウェアだ。PostgreSQL専用のシンプルなコネクションプーリングサーバであるpgpoolとは異なり、Oracle、MySQL、IBM DB2、MS SQL Server、Sybase、Interbase、SQLiteなど、一般的に使用されているほとんどのデータベースに対応する高機能なシステムとして開発が進められている。また、C/C++、Perl、PHP、Python、Ruby、Java、Zopeなど、多くの言語向けの独自APIが用意されており、柔軟にデータベースアプリケーションの開発が行える。SQLrelay向けに開発されたアプリケーショ
RubyでMySQLを使用するには、2つのライブラリがあります。 Ruby/MySQL 長所 Pure Rubyなので、コピーするだけで使用できます。 短所 MySQL/Rubyよりも低速です。 MySQL/Rubyで使用できる機能の一部が使用できません。 MySQL/Ruby 長所 MySQL/Rubyよりも高速です。 短所 インストールにCコンパイラとスーパーユーザの権限が必要です。 インターフェースに互換性があります。 Ruby/MySQLのインストール ダウンロードしたファイルを展開し、install.rb を実行します。 # ruby install.rb mysql.rbを手動でコピーしてインストールすることもできます。 使用方法 mysq.rbをロードする require 'mysql' データベースに接続する #db = Mysql::new("host", "user",
A Ruby interface for the SQLite database engine. Development Status: 5 - Production/Stable Intended Audience: Developers License: BSD License Natural Language: English Operating System: OS Independent Programming Language: Ruby Topic: Database Engines/ServersRegistered: 2004-05-10 13:53 Activity Percentile: 97.74% View project activity statistics.
軽量・高速なデータベースSQLiteをRubyから扱うためのライブラリ。 インストール Windowsの場合 RubyForgeから、 sqlite3-ruby(sqlite3-ruby-x.x.x.zip)をダウンロードする。 ダウンロードしたファイルを展開する。 インストールプログラムを実行する。 ruby setup.rb config ruby setup.rb setup ruby setup.rb install RubyGemsを使う場合 RubyGemsをインストールした後、 次のコマンドを実行する。 gem install sqlite3-ruby SQLiteのインストール SQLite Download Pageから、 sqlitedll-3_x_x.zipをダウンロードする。 ダウンロードしたファイルを展開する。 sqlite.dllをパスの通ったディレクトリにコピ
SQLiteは、簡易ながらSQL仕様をほぼサポートするデータベースソフトウェアです。PHPとこのSQLiteを組み合わせて、データベースWebアプリケーションを構築できます。 SQLiteは組み込み専用のDBMSで、PHP5からバンドルされています。SQLite単体はhttp://www.sqlite.org/から入手できます。SQLiteはパブリックドメインとして提供されており、無償であるだけでなく、ソースコードの改変や第三者への再配布も自由に行うことができます。 SQLiteの動作を一言で表せば、ファイル操作をSQL言語で行うようなものです。MySQLやPostgreSQLなどのデータベースサーバーと違って、サーバープロセスを起動する必要がありません。このため、気軽に利用できます。構成は1つのデータベースにつき1つのファイルから成り、ユーザーという概念はなく、アクセス制御などはOSのユ
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
[Contribution to Japan PLoP] RDBアプリケーションのためのデザインパターン RDB とオブジェクト指向 パターン記述のきっかけ パターンの紹介 このパターンに期待すること RDBとオブジェクト指向 リレーショナルデータベースとオブジェクト指向アプローチには、「表を中心とする集合演算」と「オブジェクトの相互作用」という、セマンティクスギャップ(意味的ギャップ)があり、両者のマッピングは水と油などと言われることもあります。確かにオブジェクト指向データベースを適用できれば非常に簡単に永続化をすることができますが、既存システムとの共存やSQLベースの検索ツールへのニーズなどから、RDBを適用するケースはまだまだ多いようです。 データベースの概念スキーマ設計や、論理レベルの実体関連図は、オブジェクト指向アプローチでの分析段階のモデリング(概念モデリングやドメイン分析など
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
PofEAAのサンプルで、商品の区分によって料金の計算方法が違う場合の処理の書き方というのがあって、冗談で「区分テーブルにJavaScriptとかGroovyとかのスクリプトを持っとけばおk」と言ってみたんだけど、あながち使えないわけではない手法なんじゃないかと思ってみました。 サンプルでは、商品としてソフトウェアを扱っていて、その区分が「表計算」「文書作成」「データベース」というのがあってそれぞれ収益の計算方法が違うことになっているのですが、普通にプログラムとして書いてしまうと区分が増えたり計算方法がちょっと変わったりするたびにシステム屋さんにお伺いをたてないといけなくなるわけです。 そういうのを、システム屋さんを通さず使う人が自分達でどうにかしたいという要求は必ずあると思うので、その場合にはデータベースに計算ルールを入れるのは有効かと。 で、そのとき気になる信頼性の問題ですが、「区分テ
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version. Copyright 1997-2007 MySQL AB This documentation is NOT distributed under a GPL license. Use of this documentation is subject to the following terms: You may create a printed copy of this do
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く