タグ

ormに関するkoda3のブックマーク (4)

  • 我々はいかにして技術選択を間違えたのか? 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ

    どうも!アプリケーション基盤チームの横田(@yokotaso)です! kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。 同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。 失敗をあえて公開する点で斬新かつ濃いブログ記事となっております! 失敗体験の公開は恥だが役に立つ! 移行先の選定の失敗 移行先として選定したプロダクトは Hibernate*1です。 Hibernateを選んだ理由としては Spring Framework を選定した Spring Frameworkで Interface + アノテーションでプログラミングするならSpring Data JPA が有力 JPAに準拠したのORMの中でも、H

    我々はいかにして技術選択を間違えたのか? 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ
  • ORMは不快なアンチパターン | To Be Decided

    このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM

    koda3
    koda3 2016/03/30
  • もう二度と、絶対にMongoDBを使うべきじゃない理由

    MongoDBは悪だ。なぜならそれは… …データを無くす(ソース:1、2)。 …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした( 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった)。 …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている(ソース:3、4)。 …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる(ソース:4)。 …ロッキングに問題がある(ソース:4)。 …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2年かかった(ソース:5)。 …ACID特性に準拠していない(ソース:6)。 …拡張やメンテナンスをする

    もう二度と、絶対にMongoDBを使うべきじゃない理由
  • Go言語でActiveRecordライクなORMをつくった

    Goで DataMapperじゃなく、ActiveRecordライクにDB操作したいと思ってつくってみました。 go/parserとgo/astでソースを解析、個々の構造体ごとにARなコードを生成します。 argen ActiveRecord** Gen**eratorでargenです。 クイックスタート テーブルを表す構造体に+ARアノテーションをマークします。

    Go言語でActiveRecordライクなORMをつくった
  • 1