
Content-Length: 244460 | pFad | http://b.hatena.ne.jp/phista/sql/
UPDATE文にエイリアスをつけてサブクエリでいろいろとしている場合、 (たとえば UPDATE HOGE_TABLE AS H SET HOGE_COLUMN=1 WHERE (・・・)のようなSQL文) PostgreSQL8.3.xでは問題なく実行できるが、PostgreSQL8.1.xでは実行できない。 ERROR: syntax error at or near "as" となる。 もうバージョンが古いのでバージョンアップすればよいのだが、どうしてもSQL文で何とかしなければならない場合がある。というかあった。 UPDATE文にもFROM句があるとのことで、下記のように修正したところ、問題なく動きました。 UPDATE HOGE_TABLE SET HOGE_COLUMN=1 FROM HOGE_TABLE H WHERE (・・・) postgreSQLのnow()関数をよく使
テーブルロックモードの関係を把握しやすいように図で表してみました。 () 内はそのロックを自動的に獲得するクエリです。 ■ロックとトランザクション SQL における排他制御の方法として、トランザクションとロックが挙げられます。 複数のクエリをトランザクションでひとつにまとめることで、(デフォルトのトランザクションレベル READ COMMITTED の場合)コミット済みの結果のみ参照されるようになり、トランザクション中の内容を外部からは見えなくなるため一見アトミック性が守られるように見えます。 しかし、複数の接続で同時に既存の同じレコードに対して参照と更新を分けて実行する場合などはトランザクションだけでは限界があるのも事実です。 たとえば以下のテーブルを考えてみましょう。 CREATE TABLE foo ( id int NOT NULL, — 商品の識別番号 price int NOT
2008年7月24日木曜日 PostgreSQLでint型のカラムに対しての曖昧検索 ども、まっつんです。 表題の事がわかったので忘れないようにメモ。 普通、文字型のカラムの曖昧検索の場合、 select * from customers where name like '%文字%' のように書けばできるのですが、これがint型のカラム(idとか)に対して行うとPostgreSQLに怒られる。 これを回避するには、 select * from customers where id::text like '%12%' と書けばいいらしいです。参考になれば。 投稿者 まっつん 時刻: 18:32:00 0 コメント: コメントを投稿
学校でSQLを使って、データベースを作るという期末課題がでました。 当方バイクの知識が少々あるため、バイクとバイク販売店というデータベースを作ってみることにしました。 バイクのデータ100個分とお店のデータは10個ほどなのですが、課題の条件の中にVIEWを作成すること、とあるのですが、VIEWとは何者なのでしょうか? 授業のページを見ても、難しい事しか載っていなくて困っています。 またテーブルの入力と、データの入力はなんとか覚えたのですが、VIEWの作り方は全く意味がわかりません。なので・・・ VIEWの意味と役割を教えてください。 初心者なので出来るだけわかりやすく教えていただけたら幸いです。 またVIEWの作成方法(create viewだとかなんとか・・・)を教えてください。 ちなみにテーブルデータとかはこんな感じに作っております。なのでこんな感じでVIEWの作成方法をご教授いただけ
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
postgresql.confの設定を書き換えたので再起動しようと思ったらなぜか出来なかった。いろいろ調べてみたが、意外と手こずってしまい苦労した。症状としては # pg_ctl restart postmaster successfully started upとは表示されるものの、実際はps aux | grep postmasterしてみてもそのようなプロセスは走っておらず、psqlしてみても蹴られてしまう。で、いろいろ見てみるとどうやら /tmp/.s.PGSQL.5432.lock /tmp/.s.PGSQL.5432 というファイルが邪魔らしい。消してから再びpg_ctlしてみたら直った。焦ったー。 原因として、他にはshared_bufferの値を上げすぎると起動出来なくなるらしい。これも注意。shmmaxとの兼ね合いを考えないと。
WHERE句で条件に指定する列なら何でもかんでもインデックスにすればよいかというと、そんなことはありません。何で読んだか忘れましたが、検索時のヒット率(該当件数 / 全体件数)が概ね10%程度まででないと、インデックスによるパフォーマンスの向上は期待できないそうです。 一例ですが、男女ほぼ同数の会員データで性別の列にインデックスを付けても効果は期待できない、ということです。(半数がヒットするので、全表走査と大差ない)
皆さんも日々SQLを組んでいれば、遅いSQLに何度となく遭遇し、ストレスを強いられてきた経験をお持ちのはずです。投げたら最後、1日たっても結果が返ってこないうえに帰ってきたと思えばエラーだった、なんてね。 このページでは、SQLの実行速度を速くし、少ないメモリで実行するためのテクニックを紹介いたします。と言っても、実は『プログラマのためのSQL 第2版』の受け売りがほとんどでして、この本を読んでいただければ、ここを読む必要はありません。 また、SQLの最適化の実行前と実行後で、SQL文の解析結果を比較することが重要です。適当にSQLをいじって速くなったからそれでよし、という非科学的な態度じゃダメですよ。SQLの解析方法については、別の文章で説明します(ただしオラクルのみ。僕がオラクルしか使ったことがないので)。 なお、SQLの応答速度が遅い場合、その原因はSQL単体にあるとは限りませ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
DBアプリケーションを作成する際、デッドロックを回避するために考慮すべき点のまとめ。 ここに書くことは、今までの経験 (Oracle) を思い出し、「こうすればコーディング時点でデッドロックを回避出来るんじゃないか」と、捻り出したので、多少間違いがあるかもしれません。 後日、PostgreSQLにて検証してみようと思います。 1. 同一トランザクション内の複数テーブルアクセス デッドロックの説明でもっともわかりやすい基本的な例として引用されるパターン。 例えばA, Bというテーブルがあるとき、二つのトランザクションで トランザクション1 : A -> B トランザクション2 : B -> A の順にテーブルの更新アクセスをしていると、同時にアクセスされた時にデッドロックとなる。 (実際は同一レコードに対してアクセスした場合) 対策: ・ コーディング規約として、同一トランザクション内のテー
ロックの仕組み(その2)-オブジェクトのロックタイプ 前回「第27回 トランザクションの一貫性を保証するロック」は、トランザクションの4つの分離レベルの説明をしました。今回は、この分離レベルを実現するデータベースサーバのロック機構に触れてみましょう。実際にどのような仕組みでデータベースサーバがロック制御を行っているかを理解することで、トランザクション機能を利用した際に起こりやすい問題点を、あらかじめ予測できるようになると思います。 今回は、初めに、ロックの状態を取得するシステムストアドプロシージャ「sp_lock」の定義を若干拡張した「sp_lock_detail」ストアドプロシージャを作成しましょう。
PHP+PostgreSQLを勉強中です。 PostgreSQLのデータ型についてについて教えてください。(PHPで) あまりに初歩的な質問ですがよろしくお願いします。 なぜデータ型が色々あるのでしょうか? 書籍を見ると例えば商品の単価には「INTEGER」を使うと書いてありますが、その理由が見当たりません。 素人考えではどんな項目でも「TEXT」を使えば簡単なのにと思うのですが、 「TEXT」にしないでわざわざ「INTEGER」にするのには何らかの理由があると思っています。 その何らかのメリットやデメリットを教えてください。 例えば○○○というデータ型を使うと「データのサイズは大きくなるが検索が早くなる」など。 こんな感じで下記の項目にはどのデータ型を使うのがおすすめなのでしょうか。 またその理由もあるようでしたらお願いします。 個人情報データの ・年令 ・郵便番号 ・住所 ブログやサイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/phista/sql/
Alternative Proxies: