タグ

関連タグで絞り込む (10)

タグの絞り込みを解除

Programmingとsqlに関するdecoy2004のブックマーク (8)

  • 物理サーバを選定する際のポイント – Eureka Engineering – Medium

    Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

    物理サーバを選定する際のポイント – Eureka Engineering – Medium

  • 新著が出ます：『SQL実践入門』 - ミックのブログ

    4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

    新著が出ます：『SQL実践入門』 - ミックのブログ

  • JavaでRDBデッドロック検出 - Qiita

    http://cs.hatenablog.jp/entry/2013/07/09/234554 RDB操作でデッドロックは不可避です。ご確認ください。 DBでのデッドロックの発生は、直ちにシステムが停止することを意味しません。DBMSはデッドロック発生を検出してトランザクションを失敗させる機能を持っているからです。 アプリケーションの開発者がすべきことはただ一点、 デッドロック検出時のリトライ です。更新処理だけじゃないです。参照処理でも忘れちゃいけません。約束です。 Javaの場合デッドロック発生はコード的にどう検知すればいいかというと、SQLExceptionが内部にSQLSTATEというRDB共通のエラー番号を持っているのでこれで判別可能となっています。 SQLSTATEの一覧は日立さんのこのまとめが役に立ちます。拝承。 http://www.hitachi.co.jp/Prod/c

    JavaでRDBデッドロック検出 - Qiita

  • SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？

    https://2021.pycon.jp/time-table/?id=273396 Webアプリ開発とデータベースマイグレーションには密接な関係があり、Pythonでよく採用されるDjangoやSQLAlchemyには、DBのスキーマを変更するマイグレーション機能があります。一般的に、プログラムを実装するときはリポジトリでブランチを作りそれぞれのブランチで実装作業を進めます。Webアプリの開発でも同様ですが、各ブランチでDBスキーマを変更する場合には注意が必要です。例えば、複数のブランチで同じテーブルのカラムを追加して使いたい場合や、DBスキーマの変更が競合する場合は、ブランチのマージ時に競合してしまいます。多くの機能を並行開発したり、マージするまでの期間が長い場合には、このような競合が増えてしまいます。 このトークでは、Djangoを例に、データベースマイグレーションの仕組みから、実

    SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？

  • S2Dao リファレンス

    TABLEアノテーション テーブルとの関連付けはTABLEアノテーションを使用します。 TABLEアノテーションは以下の形式で定数を宣言します。 - public static final String TABLE = “テーブル名”; EMPテーブルの場合以下のようになります。 public static final String TABLE = "EMP"; スキーマの定義をすることも可能です。スキーマ名が"SCOTT"の場合は以下のようになります。 public static final String TABLE = "SCOTT.EMP"; ※クラス名からパッケージ名を除いた名前がテーブル名と一致する場合は、TABLEアノテーションを定義する必要はありません。 また、dao.diconでorg.seasar.dao.impl.DecamelizeTableNamingを指定している

    S2Dao リファレンス
    decoy2004
    decoy2004 2009/07/23
    テーブルとの関連付けはTABLEアノテーションを使用します。
    リンク

  • Seasar2 - S2JDBC - JdbcManager - SQL自動生成による操作

    List<Employee> results = jdbcManager .from(Employee.class) .getResultList(); 検索するエンティティは、 from() で指定します。 デフォルトでは、結果がなかった場合は、 空の List が返されます。 disallowNoResult() を呼び出すと、 結果がなかった場合は javax.persistence.NoResultException が発生します。

    decoy2004
    decoy2004 2009/07/23
    フェッチサイズを指定する場合は、 fetchSize() を使います。
    リンク

  • トランザクションでデータの不整合を防ぐ

    トランザクションの構成と実行 今回は、トランザクションの構成と実行に挑戦します。トランザクションは、複数のユーザーが同時にデータベースを操作する状況において、データベースに対する複数の操作（選択、更新、削除など）を実行している途中で仮にエラーが発生したとしても、データの不整合が起きないことを保証するリレーショナルデータベースシステム（RDBMS）のメカニズムです。 これまでの連載において紹介してきた例題では、同時にデータベースを操作するユーザーは1人であるという暗黙の前提において説明をしてきました。しかし、RDBMSを利用したアプリケーションでは、複数ユーザーによる同時利用を前提とすることがほとんどだと思います。このため、RDBMSにはデータベースを同時に更新した場合にデータの不整合が起きないように制御をするための仕組みが用意されています。 では早速、例題を実行しながらSQLの確認をしてい

    トランザクションでデータの不整合を防ぐ

  • トランザクションの一貫性を保証するロック

    ロックの仕組み 第25回、26回と2回にわたりトランザクションの話をしてきました。第25回でも簡単に触れましたが、トランザクションの一貫性を保証するために、データベースサーバはロックという仕組みを利用しています。今回と次回にわたって、このロックの仕組みについて解説することで、トランザクションの裏側を解明したいと考えています。 では早速、例題を実行しながら、SQLの確認をしていきましょう。 トランザクション中の最新データを確認する 初めに、第25回で実行した例題1と同じような例題を実行してみましょう。第25回の例題1は、1人のユーザーがデータを更新中には、もう1人のユーザーはデータの参照ができないことを確認する例題でした。第25回の例題と同様に、2つのクエリアナライザを起動して、片方はログイン名「sa」で、もう片方はログイン名「yamada」でログインをします。 では、まず例題1でログイン名

    トランザクションの一貫性を保証するロック
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2025 Hatena. All Rights Reserved.