PostgreSQL 2テーブル目at PHP
PostgreSQL 2テーブル目 - 暇つぶし2ch620:nobodyさん
07/06/17 00:27:42 Yzi7QEQY
頭を悩ましているのでお願いします。

営業時間を入力しておいて、今営業中か検索できるようにしたいのですが、
open_timeとclose_timeという型がTIMEのカラムを作って、検索したときの時間が
その間にあるか、例えば
SELECT open_time < localtime AND localtime < close_time
で検索できそうだと思っていたのですが
よく考えたら、深夜24:00以降やってるお店が、うまく扱えないじゃないですか。

で、TIMEをやめてFLOATにして、保存するときに、例えば
10:30~3:00 → 10.5~27
にして、大小で検索も考えたのですが
検索するときに現在の時間が例えば5時なら、どう検索すればよいのか・・・
この方法もなんかうまくいかなそうです。

また24時間営業の店はどのように扱うのかとか・・・

このようなシステムを作ったことある方いらっしゃいましたら、どのように実装したか教えて頂けませんでしょうか?

621:nobodyさん
07/06/17 00:58:26
>>620
開店時間(open_time::time)と営業時間(sales_hours::interval)で
WHERE (localtime - open_time) < sales_hours
でどうかな。開店後何時間経ってるかで比較する。

622:620
07/06/18 01:48:25 3Ht3k2HG
>>621
レスありがとうございます。

それだと、0:00を過ぎたときマイナスの値が帰ってきてしまうので
WHEREがtrueになってしまうと思うのですが。

timeだと日にちが変わったことが解らないからなのかな?

例えば、CRONを毎日0:00に起動して、営業時間を入れたカラムを見に行って
数日分(あんまりじっくり考えてないけど、その日と翌日分で良いのかな?)
の日付入りのテーブルを自動生成して、そこに検索かけるとか・・・

今が営業しているか、って意外と大変ですね。
開店時間が何時より早いお店とか、閉店時間が何時より遅いお店なら簡単に実装できそう。

それでいいかな・・・

なんか簡単な方法あったら引き続き情報お願いします。

623:nobodyさん
07/06/18 03:02:36
>>622
ああスマン、open_timeをinterval型にキャストするの抜けてた。
WHERE ( localtime - open_time::interval ) < sales_hours;

開店時刻をinterval型に変換するのは反則のような気もするが、
これで、開店後の経過時間が出ます。(負の値にはなりません)

624:nobodyさん
07/06/18 03:50:30
店舗ID,開店時間,閉店時間
1, 07:00, 23:59
1, 00:00, 03:00
(朝7時から翌朝3時までの店の場合)

みたいに一つの店舗でも営業時間を二行にわけてやればいいじゃね?

625:622
07/06/19 08:04:50
>>623
>>624
超遅レスですが
レスありがとうございます

>>623
確かに、そうすると負になりませんね。
なぜそうなるのか原理というか理屈が良くわかりませんが^^;
勉強になりました。
それならいけそうです。ありがとうございます。

>>624
なるほど、それでどちらかに入っていればいいと。
それもわりと簡単。

いろりろアイデアがあるモンですな。
ありがとうございました。
よく考えて、ベンチもとって、どちらかの方法でやらせて頂きたいと思います。

626:nobodyさん
07/06/19 11:33:30
正規化するといいよ
24時以降は24足すのさ
そして範囲チェックは BETWEEN でやると見やすい

627:nobodyさん
07/06/19 18:36:18
でたな正規化厨!

628:nobodyさん
07/06/19 19:02:58
テーブルの正規化と意味が違うのに脊髄反射するやつw

629:nobodyさん
07/06/20 02:18:52
でたな性器化中!

630:nobodyさん
07/06/23 18:35:19 T/euHpQb
不可解なことでなやんどります。

複数のデータベースを作成していて、一方でVACUUMを実行したのですが、
どういうわけか、VACUUMをかけたほうだけではなく、かけてないほうで著しくパフォーマスが劣化します。

データベースA <= VACUUM実行
データベースB <= 運用中

で、遅くなっている様子が、IO負荷ではなくCPUをいつも以上に使用しているように見えます。
VACUUMの実行を中断すると通常の状態に戻るので、VACUUMと何らかの関連があると
思うのですが、VACUUMの実行によってVACUUMしていないデータベースの実行プランが
影響受けるなんてことあるんでしょうか?
誰かヒントくださいまし...

ちなみに8.1.5でございます。


631:nobodyさん
07/06/25 18:32:04
同じサーバで同じpostmasterでDBが違うだけなの?
だったら片方で負荷がかかれば足引っ張られると思うが

632:630
07/06/25 19:07:01
そうなんだけど、IOで引っ張ってるんじゃなくてまるで実行プランが変わったように突然CPU使用率が上がるんだよ。
で、VACUUMをとめても実行プランが変わるまで同じ調子でCPUがんがん使ったまま…。
ANALYZEがかかると収まる。そんな感じ。

633:nobodyさん
07/07/25 21:58:43
ムーバブルタイプというブログ作成ツールをインストールする際にポスグレを使っております。
インストールは無事に終わったのですが、
データベースのアップグレードをする際に
ERROR: parser: parse error at or near "0"
というエラー文言が出てきてしまいます。
通常は"0"の部分に原因となるヒントが出ているものなのですが、
0とだけ出ていても何が原因なのかが全く把握できません。
この0っていうのはどういったケースで発生するものなのでしょうか??

634:nobodyさん
07/07/26 01:11:19
>>633
"0" 付近で構文解析エラー
ってころだろ。
"0"に特別な意味はなくて、SQL文中に"0"が出現したところあたりが怪しいってことだ。
勝手に想像すると、"SELECT * FROM ${table}0 ;" 見たいなSQLで
変数$tableが空だった為に正しいテーブル名が渡せなかったとか。

635:nobodyさん
07/07/26 10:24:17
デバッグ出力時に、sqlも吐いとくとわかりやすい。
DB側のログに出すことも可能ではあるが

636:nobodyさん
07/07/26 11:34:31
>>634-635
ありがとうございます。
参考になります。
これからソースとにらめっこ&デバッグして原因を探ってみます!

637:nobodyさん
07/07/26 13:13:51
DBを一旦削除したあともう一回作ったら何故かうまく行きました。。
特に何もしてないんのだけど。。
作成にミスるって事もあるのかなぁ。

638:nobodyさん
07/09/22 21:58:23
Perlで辞書検索CGIを書きましたが、DBI/DBD::Pgのあまりの遅さに辟易して、Pg使ってます。
各モジュールのパフォーマンスに関する記述ってあまりないようなんですが、皆さんはどちらを使っているのでしょうか。


ちなみに、作成したCGIはSELECT文を1回実行するもので、Dprofでプロファイリングしてみると
CGI全体でDBI/DBD::Pgで800ms、Pgで600msかかっていて、いずれも::INITで時間がかかっていました。

639:nobodyさん
07/10/09 20:34:44
1台のPostgreSQLサーバーにデータベースをたくさん作っていたのですが、
これを1つのデータベースにまとめる方法はありませんか?COPYではできませんよね?
なお、テーブル名に重複はありません。


640:nobodyさん
07/10/23 17:46:23
COPYでできると思うけど。
まあ、
pg_dump DBNAME1 | psql DBNAME2
とか繰り返せばいいんじゃない?
って久しぶりに見たからえらい遅レスになっちまった

641:nobodyさん
07/12/20 15:45:11
あるテーブルからSELECTする際に「別のテーブルに含まれていない」という条件を「Not IN」とかで
指定できたと思うんですが、この「Not IN」って名前なんて言うでしたっけ?
構文とかが良くわからないからGoogleろうと思ったけどnotとinって一般的過ぎて検索ワードにならないです
サブクエリ(副問い合わせ)だったかと思ったけど違ったし…。
URLリンク(www.postgresql.jp)
にはNot IN自体載ってなかった…。

bash-2.05$ psql -V
psql (PostgreSQL) 7.1.3

642:nobodyさん
07/12/20 16:53:36
>>641
IN述語でググれ。

よく「句」と間違えている人がいるようだが、
INやEXISTSは述語な。

643:nobodyさん
07/12/20 17:16:36
>>642
ありがとうございます
ただ、「IN 述語」だと9万件以上引っ掛るのに
「IN 述語 postgre」だと30件ちょい…。

とりあえず↓がおもしろそうだから読んでみます!(・∀・)
URLリンク(www.geocities.jp)

644:641
07/12/20 17:30:18
>>642
わかったー
SELECT カラム from テーブル where カラム IN (SELECT カラム from テーブル2);
で生けました。

PostgreのマニュアルってPHPのそれよか充実してないですよね…。
どっかいいサイトあったら教えてください

645:641
07/12/20 17:33:19
連投ごめんなさい
>>2にあった
PostgreSQL7.1マニュアル全文検索
URLリンク(osb.sra.co.jp)
これ、500エラー吐いてるけどタマタマですかね?
メンテされないのであればテンプレから外した方がいいのかな、と思いました。
1スレで4年以上もつからしょうがないけどw

646:nobodyさん
07/12/20 17:47:31
>>645
みんなDB板 URLリンク(pc11.2ch.net) に行ってるんで、
このスレは死に体。

647:nobodyさん
07/12/20 17:51:35
>>643
せめて 「IN述語 PostgreSQL」でググれよ。

>>644
それだと 相関クエリをつかったEXISTSの方がいい。
特に7.1.xならなおさらINはなるべく回避してEXISTSを使うべき。

648:nobodyさん
08/01/14 16:29:28 VAusV2xL
>>304にもあるけど、
postgresってrollback使えないんですか?

# select count(*) from *****
count
-------
11419
(1 row)

# Insert into ***** ( ***,***,***) values(2,1,'14-May-07');
INSERT 0 1

# rollback;
WARNING: there is no transaction in progress
ROLLBACK

# select count(*) from ors_win_lose_manage;
count
-------
11420
(1 row)

こうなってしまうのはなぜでしょう?





649:nobodyさん
08/01/14 16:33:02
>>648
begin;

650:648
08/01/14 16:41:15
>>649
おぉ。。。ありがとです。


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch