O/Rマッパーによるトラブルを未然に防ぐ「ORMがトラブル起こすから嫌い」なんじゃなくて、「ORMが起こすトラブルが解決できないから嫌い」ってのがほんとのところじゃない？だったら解決方法を知ればいいんじゃね？というお話。「N+1問題」もろくに知らずにORMを批判せんでほしい。
MEANスタックは破壊的か
最近、MEANがイイという話をチラホラと耳にする。先日も次の記事がはてブで話題になっていた。 MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog この記事の冒頭では、MEANはLAMPに変わる技術として紹介されているが、果たしてそれは正しいのだろうか。（この記事では、LAMPを例にとりつつJavaがどうのという記述があるので、恐らくはLAMPではなく既存のリレーショナルデータベースを用いたアーキテクチャ一般について述べたいのではないかと思う。）MEANについて少し思うところがあるので、今日はMEANの可能性について書き綴っておこうと思う。ただし、私自身MEANスタックと呼ばれるシロモノは使ったことがなく、構造を理解した上
DBA考
DBA考 少し元気なので久しぶりに記事を書いてみる。 DBAとは何だろうとふと考えた。 DBA = DataBaseAdministrator ってのはわかる。 けど、DBAを自称する人たちは何らかのシステムにおいて例えばRDBの世界でだけモノゴトを考えてしまう傾向に縛られてはいないだろうか。 SSOの認証情報をRDBにため込む？Active Directoryと連動させる可能性を模索しただろうか。 頻繁にアクセスが発生するユーザ個々のトランザクションデータを効率よく扱えるためにバッファキャッシュに乗せる策を講じる？memcachedを入れたりあるいはクラスタリングしたWebLogicのセッション情報においておけば済まないだろうか？ ここまで書いて思ったけど、私は多分DA(Data Administrator, 私の今作った造語)と仕事をしたいのかもしれないと思った。それはITアーキテクト
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
「サロゲートキー vs 複合キー」という間違った対立 - ネットの海の片隅で
DB設計についてググっていると、「サロゲートキーは使うべきではない」や「複合キーは使うべきではない」といったDBのキーに関する論争をよく見かけます。 それらを見ていると、多くの議論で「これって対比の軸がズレてないか？」と思いました。 正しい対比 正しいと思う対比とそのざくっとした意味。 自然キー vs 代替キー 自然キー（Natural key） キーそのものに意味が含まれているキー。 都道府県を含むテーブルprefecturesがあったとして、都道府県名prefectures.nameは自然キー。 代替キー（Surrogate key）*1 キーそのものには意味が含まれていないキー。 前述のprefecturesの例で言えば、システム内部のみで使用されている都道府県コードprefectures.codeは代替キー。*2 単一キー vs 複合キー 単純キー（Simple key） 単一のカ
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
【チラ裏】あなたは本当にそのデータストアが好きで使うんですか？ - oranie's blog
チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか？みんなが使い慣れている物から変える理由は「有名な会社が使っていて＾＾」「他のチームが使っていて＾＾」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか？ もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか？ 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか？ まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか？ あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか？他のメンバーへの啓蒙や情報共有を率先
デベロッパーとデータベース管理者は手を取り合うべきだと、マーチン・ファウラー氏
デベロッパーは官僚的なデータベース管理者を嫌って、管理不要のNoSQLデータベースを希望することがあるけれど、両者が手を取り合うことの方が重要だ。マーチン・ファウラー氏は先週、「NoDBA」という記事を自身のWebサイトにポストしました。 デベロッパーによる最新の開発手法の採用とその壁、NoSQLデータベース、DevOpsといったITのキーワードを含むこの記事は翻訳が許可されているため、日本語訳してみました。 NoDBA 多くの組織において、保存が必要なデータは情報部門が集中管理するリレーショナルデータベースに収まることだろう。情報部門が集中管理する理由はそれぞれだが、統合的なデータベースの運用が一般的な理由だろう。データを管理している部門は、変なデータが紛れ込まないか、データベースを遅くするようなクエリが実行されたりしないか、企業全体で一貫性のあるデータモデルが実現されているか、といった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
