2010年12月26日

商品コードを主キーにするべきではない理由

リレーショナルデータベースのテーブルの主キーの設計については「ユニークになる項目だから必ず主キーにしないと行けない」というわけではなく、多くのDB設計者の間でも

- ID派(あえて別に自動採番のIDを付ける)
- コード派(ユニークになるものは出来るだけ主キーとする)

の2つに分かれる様だ。特に近年はRuby on Railsに代表される様に数値型の単一キーの存在を前提として作られているFrameworkが増えて来た事もあって、ID派の存在感が増しているらしい。

それぞれメリット・デメリットがあってどちらがいいのかはケースバイケースになるのかも知れないが、自分の場合はこれまでの業務システム開発の経験から、どちらかと言うと自動採番のIDを使う方がメリットが多いのではないかと思っている。やっぱりなんだかんだ言っても、「どうしてもこのマスターのコードを変えたいんだけど」と言われるケースが何度かあって、コードを主キーにしている場合に結構面倒な作業になってしまった事があるからだ。

ただ今回はあるプロジェクトにおいて「コード派」の技術者の方をやんわりと説得する必要があったので、「ID派」の根拠になりそうな情報を少し調べて見た。せっかくなので今回参考にさせてもらったサイトの引用とURLなどをまとめておこうと思う。

まずその前にひとつ思った事は、「主キーにする為にあえて付与したID」の事は「サロゲートキー(代理キー)」と言うよりも、「人工キー(Artificial Key)」と呼ぶ方がしっくり来る気がするという事だ。もちろん引用は原文のままにしておいた。


「サウスポーなSEの独り言 - テーブル設計」
テーブル設計上、どっちが良いか(…)ですが、私はお客様の要望が無ければサロゲートキーを採用します。
ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。...

「ぼそっと - 人は何故PKに人工キーを用いるのか」
メリット
- 変更に強い
- 自然キーの場合、複合キーがめんどくさい
- 最近のデータベースアクセスソリューションもの(平たく言うと、広義の意味でのORM)と相性が良い
デメリット
- 関連が分かりづらい
- ベテランの技術者は自然キーに慣れている人が多く、なかなかコミットしてくれない
- 既存システムはまだまだ自然キーのものが多いので、他システム連携的なところとは相性が悪いことが多いくらいにしか思っておらず、ようするにビジネス的な変更がシステムに与える影響を小さくする、一種の粗結合的なものだと思うのですが、...

「@IT - システムの寿命はコードで決まる!」
業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。...

「Life goes on - 楽々ERDレッスンを読んでいます」
アプリ側の視点からすれば、業務コードを主キーに使うような下のような設計はもうありえないと思います。(...)主キーには業務上で一意に識別されているコードではなく、意味もないIDを使いましょうというのが今の主流だと思います。...

「Hot Heart, Cool Mind. - 主キーの設計①」
これはかなり以前からある論争で、大雑把にいうとコード派とID派という二つの立場の間で戦われている。
コード派 ... ユーザの目に触れるデータ項目(典型的にはコード)を主キーとする。複合主キーを許す。
ID派 ... ユーザの目に触れないデータ項目(自動生成したID)を主キーとする。複合主キーを許さない。...

「A.R.N [日記] - ID or not ID」
たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるような場合、いったいいくつ項目持てばいいのかわからないくらい項目が増える場合がある(まぁ大半は設計が悪いだけだったりするのだけど、ID派の立場を取ればそもそもそのような状況はおこらないことを考えれば欠点には違いない)。
個人的には、複合主キーだとマスタに履歴を持つようなケースで変な主キーを選択しなければならなかったり、主キーを更新せざるを得ない場合があって気持ち悪いので、ID派ではあるけど、絶対にIDじゃなければダメだということを説得できるだけの論点が見出せないのが実情。...

「DBFlute - サロゲートキーと複合主キー」
ナチュラルキーをPKにするということは、業務に直結していて実装上でも直感的でありながら、 直結しているがために業務の変更の影響をもろに食らうということにつながります。確かに変更が発生するのは仕方のないことではありますが、 その影響は最小限にしたいものです。そのためには、テーブル間の依存関係を薄くすることが重要です。
サロゲートキーを導入することで、テーブル間の依存度合いは減り、業務変更のインパクトも(何もしない状態よりは)少ないものになります。 複合主キーの場合の方が効果は顕著ですが、単一キーでも同じ話です。例えば、ExampleDB の商品テーブルは、単一のナチュラルキーである商品ハンドルコードでユニークですが、商品IDというサロゲートキーを利用しています。 商品ハンドルコードは、業務で利用する値であり、業務変更でコード値の構成変更が発生する可能性があると想定したものです。

2010年12月13日

AndroidでiPhoneに匹敵する楽器アプリの作成が困難な理由

Androidでも楽器アプリが出ているけど、試してみるとどれも今ひとつ反応が鈍い、というか画面をタップしてから実際に音が出るまでにタイムラグがあるのがはっきりと感じられる。

iPod Touchだとほとんどタイムラグは感じられないので、この差は何なんだろうと気になった。Androidの仕様上の制限なのか、アプリに原因があるのか。。。

自分でも音楽関係のアプリはいつか作ってみたいリストに入っているので、Androidで任意の音を自由なタイミングで鳴らす方法を調べて見た。Google検索で一応大雑把な所は分かったので、とりあえずメモしておこう。

以下、自分でコーディングして試した結果ではないので「~らしい」「~みたい」ばかりになって恐縮ですが。

Androidで音を鳴らす方法


下の4つの方法があるとの事。それぞれ向き不向きがあるみたいだが、「リアルタイムで任意の音を鳴らす」という用途にはどれもいま一つらしい。(少なくともタイムラグを無くすのは困難みたい。)

1. MediaPlayer

予め作成された音楽を鳴らすのに向いている。
MIDIファイルの演奏も可能。ただしメモリ上に動的に生成されたMIDIデータを演奏させる事は出来ない。一旦一時ファイルに保存する必要がある。

2. JetPlayer

「JetCreator」というツールを使って予めMIDIデータから「JETファイル」という形式に変換しておくと、そのファイルの任意の部分を演奏させる事が出来る。ゲームの効果音などを出すのに向いている様だが、楽器アプリとして自由な演奏をするのにどこまで向いているかは、試して見ないと何とも言えない。
hidecheckの日記 - AndroidでmidiとかJetCreatorとかで鍵盤アプリとか作成
3. SoundPool

MIDIではなくOGGやWAVなどのサウンドファイルを使った効果音を再生出来る。
しずくくんのAndroidでゲームプログラミングしてみたいなblog
むずかしいことはわかりません。

(2011/05/11 追加)
SoundPool使用上の注意点 - Hacking My Way ~ itogのhack日記
4. AudioTrack

PCMデータを直に操作して音を鳴らす場合に使う。(実は良く分からない。^^;)下のソースコードとかを見ると面白そうではあるけど、楽器の音を作るのはかなり大変かも。
にュウさいと - AudioTrackを使う
Androidアプリ開発 / 夢見る少女の開発メモ - 音を作ってみる

(2011/05/11 追加)
たいてい自宅で迷想中 AudioTrackをAudioQueueのように使う

さらに英語でも検索して見た。


英語だと結構核心に踏み込んだ(と思われる)情報があった。
Umito - The state of MIDI support on Android

Stack Overflow - Dynamic Midi generation and playback on Android: Possible?

Google Code - Expose Midi Streaming capability of Sonivox Synthesizer.

Pragmatic Bookshelf - Java SE5 javax.sound (MIDI) classes removed from Android libraries?
やっぱりMIDI音源に対して直接リアルタイムでコマンドを送信する為のAPIが用意されていないというのが致命的なようだ。


現時点での結論(Android 2.2以下の場合)


で結局、今の所はこちらに書いてある通りAndroidの仕様上の理由からiPhoneに匹敵するようなレスポンスの良い楽器アプリを作るのはかなり厳しいようだ。
【combuのDTM & ミキシング 】 脱初心者を目指す音楽制作 - DTMやるならAndroidを買ってはいけない





2/21/2011 追記:
Android2.3, 2.4とか3.0が出てきたので、現在は状況が変わっているかも知れない。
変化がめまぐるしいので最新情報を追いかけるのも大変だ。。。



10/21/2011 追記:
Android 4.0でもまだ改善されていないみたいだ。
Android 4.0で反応の良い楽器アプリは可能になるのか



11/20/2012 追記:
4.2になって少し改善されたみたいだ。

Android 4.2で今度こそ反応の良い楽器アプリは可能になるのか!?


10/25/2013 追記:
最近はこんな感じらしい。
このレイテンシー、Nexus10はDTM用途に使えるかも!? : 藤本健の“DTMステーション” 






 

2010年12月7日

社内勉強会を開催して思った事

今日、社内の勉強会を開催した。一応主催者という事で内容の企画とメインのプレゼンテーションは自分で行った。内容は以下の通り。(一部抜粋)

Google Appsの説明(あまり知られていないFormやScriptの機能など)
Google Sitesの紹介
Google AppEngineのアプリ開発デモ(Java/Servlet)
iPhoneアプリ開発のデモ (デモ作成・プレゼンは別の人にしてもらった)
その他IT関連で気になったニュースなど

と言った感じで、かなりGoogleのサービスに偏った内容だった。(まあ一応意図的にGoogle特集的にして見たのだけど。)
個人的にはAppEngineのデモに力を入れたかったけれど、準備があまり出来なくて結局ほんの触りの部分だけで、中途半端な印象になってしまったかも知れないとちょっと反省している。普段うちの会社ではASP.NET(VB)での開発が多いのでJavaでのデモにはみんなあまり興味を惹かれなかったかも知れない。それだけにもう少しデモアプリの内容を面白くすれば良かったかも知れない。次回はもっとしっかりと準備をしようと思う。

それにしても思うのは、規模はどうであれ勉強会でのプレゼンテーションというのは大変だけども、やっぱりやれば他の誰の為でもなく最も自分の為になるという事。準備段階で考えを整理出来るし、技術的な事も人に説明する為に調べていると自然に頭に残る様になる。話したいネタは山ほどあるので、これからも続けて行きたい。

-------------------------------------
今回参考にさせて頂いたサイト:

Google SpreadsheetのScriptから定期的にメールを自動送信する
http://d.hatena.ne.jp/d4-1977/20101130/1291126071

Google Sitesとは
http://www.isr.co.jp/product/cloudservice/apps-integration/sites-construction

Google Sitesの短所
http://wiki.slash-reader.com/home/disadvantage

Google App Engineで手軽に試すJavaクラウド
http://www.atmarkit.co.jp/fjava/index/index_gaej.html

Google Chart Tools / Image Charts (aka Chart API)
http://code.google.com/intl/ja/apis/chart/index.html

Google Analytics入門
http://web-tan.forum.impressrd.jp/e/2006/09/25/200

最近気になったニュース: 岡崎市立中央図書館事件
http://www26.atwiki.jp/librahack/pages/26.html
http://librahack.jp/