マイクロサービスと基幹システムの本質 - 設計者の発言
「マイクロサービス(microservices)」が注目されている。社内外のさまざまなシステムが提供するREST APIのような操作手段を組み合わせて、新たなしくみをアジャイルに開発・保守してゆく。そんな開発スタイルのことをいう。 もともとはネット系企業で普及した手法であるが、それ以外の企業にとっても参考になる。前回記事で、基幹システムが効果的なAPIを提供することで「周辺システム」の開発が合理化されると説明した。これを社内システム全体に適用した手法が、マイクロサービスである。ネット系企業でなくても「周辺システム」はいろいろあるので、いくらでも応用できる。ただし、当然ながら万能ではなく使いどころがある。 基幹システムから見た「周辺システム」と書いたが、それらは今風に言い換えるとSoE(Systems of Engagement)、ようするに顧客との関係強化をはかるためのシステム群である。い
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
プログラマの地位向上のためにやれること - 設計者の発言
プログラマが尊敬され高い給与を得るためにはどうしたらよいか。飲み会などでそんな話になることがある。私の答えは明快だが甘くない。 プログラマの地位を確実に高めるための手段がひとつある。結果的にプログラマの参入障壁が高まるような変化を起こせばよい。 もともとプログラミングの仕事はスキルや適性が求められるものだったのだが、ＩＤＥの発展や分業化の進展にともなって、それらが求められない（または求められなさそうに見える）コーディング作業が大量に切り出されるようになった。これが良くも悪くも業界への労働力の大量参入を許し、技術者の多くが安月給の過重労働にあえぐ状況が生まれた。 その「工数地獄」とでも呼べる状況を、経営者のサクシュだの技術軽視の風潮が生んだものだとみなす考え方は、完全な間違いとはいえないにせよ短絡すぎる。ようするに、参入障壁が低い仕事は社会で尊敬され高給を得る職業にはなりにくいだけの話だ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
