Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
リダイレクトの警告
表示中のページから https://oss-db.jp/amp/dojo/dojo_info_04 にリダイレクトしようとしています。 このページにリダイレクトしないようにする場合は、前のページに戻ってください。
技術以外に設計に影響を与えるもの - プロマネブログ
論理削除と物理削除 ソフトウェア設計を行う際に、物理削除と論理削除ってのがあります。 物理削除というのは、データを削除したいとコマンドを発行したときに、データを即座に消す設計です。 これに対し、論理削除と言うのは、データを削除したいとコマンドを発行したときに、データを実際には消さずに利用者から見えなくする設計です。windows のゴミ箱をイメージすると分かりやすいかと思います。 この物理削除と論理削除、昔からどっちを設計上で採用するんだ、でもめることが多く、さながらキノコたけのこ論争みたいになったりすることがあります。 オッサンが若手の頃は、「とりあえず論理削除にしておけば後で問題が起きたときに復旧しやすいから安心」なんて教わったりしてました。 でも、最近は「積極的な要件がない限り、物理削除とするべき」という思想になってます。 そんな風に考えるようになったのは、以下の理由があります。 そ
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
