Evernote v5.0: 写真を自動で切り抜き、補正するスキャン機能「ページカメラ」の使い方。 | AppBank枠の中に収まるように書類や名刺を撮影すると、紙の縁を認識して余分な部分を切り取り、文字が読みやすいように写真を自動で補正します。 「ページカメラ」機能は、いわばスキャンアプリそのものです。そこで今回はこの機能を使って名刺を撮影、Evernote に取り込んでみました。 ページカメラ機能を使う 左：Evernote を開いたらホーム画面上のボタンをタップします。 右：すると撮影できる状態になります。
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
「強制されたサロゲートキー」の事例を眺める - 設計者の発言
Ruby on Rails上で実装されているプロジェクト管理ツール「Redmine」をインストールした。実務で使うためではなく、前回記事で言う「サロゲートキーを強制する開発基盤」のひとつであるRails上のＤＢ設計事例を眺めてみたかったからだ。 サロゲートキーが強制される基盤上で作られるテーブル構造の特徴は、複合主キーが許されないために「親子関係」が出現しない点である。たとえば図１において、membersはuser-idとproject-idの組み合わせをユニーク制約としているが、それらは一次識別子に含まれていないので、usersやprojectsとは「参照関係」をとっている。つまりＥＲ図だけ眺めたら、memberレコードを追加した後で、user-idやproject-idの値が変更可能であるように見える。 図１ [users] id, firstname, lastname, ... ＋
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
