PostgreSQL Part.11©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
一説にはWindowsで動かせたからとも言われてるな。
日本でフリーDBMSが導入され始めた頃はPostgres7.0が出る頃だったから
MySQLじゃなくてトランザクションをまともに使えるPostgresの方に流れたとも。
ヒゲががんばって布教したってのもあるんだろうけど。 まぁ 普通の開発者、ユーザーから見れば普通に使えれば
それほど最新技術はなくてもぉ とは思うんじゃないの? PostgreSQL使い始めた頃はMySQLはサブクエリ使えなかったからなあ MySQLはデータベースとして当然備えてる機能を備えてないんだよ
商用データベースから来た人にはおもちゃにすら見えない UberがPostgreSQLからMySQLへ移行した経緯の記事と
それへの反論は興味深かった 俺のとこではmaxでも10リクエスト/sec程度なんで、あんま参考にはならなかったな いままでPostgreSQLで、ごく最近Oracle使い始めたけど、
Oracleって糞だなって思うこと多い。
Oracleをよく知らないせいだとは思うけど。
業務系、Webシステムなどでは、PostgreSQLで何も問題なし! 普通に使う分はもちろん、バックアップもフェールセーフも問題ないよね。
マテリアライズドビューなんて使った事もないし。 だからボラクルはサポートで金とってんだっつってんだろ >>113
最近は差を詰めてきてるよね
とはいえ大規模になればまだまだOracle
>>114
PostgreSQLにも一応マテリアライズドビューあるでしょ
>>115
金払わないとパッチすらくれず、払っててもバグ修正してくれないけどな >>116
>金払わないとパッチすらくれず、払っててもバグ修正してくれないけどな
何その塩対応 >>116
ポスグレのそれを使った事ないって意味ですよ。
Orackeの現場では頻繁に聞こえますね。でも結構トラブッてるようなw バグが修正されてユーザのコードが動かなくなったとき
危険なコードを書くのが悪いと言われるのがPostgres
専用の互換性パッチの見積もりをくれるのがOracle >>119
なるほど
ボラクル体質をとても明快に理解できた
そんでもってどっちがまともかは言わずもがなだな バージョンあがって動かなくなるなら、バージョンあげないだけだよ
そもそも特に困ってないのにバージョンあげるわけないだろう
ミドルウェアのバージョンが変わるなんて、5年ごとのリプレースだけだよ そのバグ修正の内容がセキュリティ脆弱性の改善でなければな データベースサーバにセキュリティパッチあてるわけないだろ (データベースサーバはインターネッツに公開なんかしないんだから、セキュリティパッチあてる必要もないだろ)
ということかな OSのパッチなのかRDBMSのパッチなのかでもかわってくるw おまえらPostgreSQLにセキュリティのためにパッチなんて当てたことあるの?
UPSERT使いたいからバージョンあげるとかだったらあるかもだけど
セキュリティなんて考えたこともない >>139
・パラレルクエリ
・同期レプリケーション / シャーディング (postgres_fdw)
・全文テキスト検索 (たぶん日本語はダメ)
って感じ?
結構なパワフルユーザ向けだな。まぁ基本はやり尽くしているんだろうけど どうしてPostgreSQLって本屋さんに本が全然ないんですか?
MySQLはたくさんあるのに 最新のシーラカンス本の対応バージョンは8くらいだったっけ? CTEやCONFLICTについてがっつり書いてるような本が欲しい となるとやっぱ最新マニュアルしかないわなぁw
そこそこ良く書けてるしわかり易いと思う。 おすすめの記事ってどこかある?
ブロガーさんやニュースサイトでも何でも
PostgreSQLについて情報が集まるようなとこ探してる さあ、みんな今こそ売り込みの絶好のタイミング
自社のURLを貼るんだ エセ左翼の目的は、わざと突っ込みどころが多い主張をすることで自分たちへ注意を向けさせ、
カルトへ向かう非難の矛先を逸らすこと。
国益に反することを言ったり、主張が食い違うもの同士の対立を煽ろうとするので放置し難いが、
主義思想についての洗脳を受けているわけではなく、フリをしているだけなので、
言い負かされてもダメージを負った様子もなく、論点をすり替えられるかスルーされる。
まともに相手をしてはならない。 pgAdmin3 は日本語で使ってるとなんかのコマンドが日本語で流れてエラーになった記憶があるので、それ以来ずっと英語で使ってる 来週末のPGConf.Asia、みんなは行くかい?
http://www.pgconf.asia/JP/ PostgreSQLって、OrderByを書かないと・・・・
毎回違う並び順になるの?
それとも、PrimaryKey順になるの? 不定だわな。たとえ何かの順に並んでたとしても信用出来ない。 >>162
一々ソーティングしなくていいから少しでも速く、省メモリで結果返して欲しいって時に勝手にソーティングされたら寧ろ迷惑だと思わないかい?
ソーティングは通常ではなくオプションとすべきだ 不定だけど、大体はINSERTした順になることが多い
UPDATEしたりするとそれが最後になったりするので
id順とはいえない
もちろん出てくる順番を当てにしちゃいけないw で、なんでそんな物理的事情で並んだ順で返すのかって言ったら、『一々ソーティングしなくていいから少しでも速く、省メモリで結果返して欲しいって時に勝手にソーティングされたら寧ろ迷惑だろ、ソーティングは通常ではなくオプションとすべきだ』ってことでないの? >>170
クラスタ化インデックスだとpk順になる。 >>170
そんなのどんなRDBMSでも同じで、実装を考えれば、そうなるだろうが。 >>171
違う。RDBのレコードはソート指定をしないかぎり不定というのが標準SQLでの仕様だから。 PHP+PostgreSQLで運用する場合、元号の処理ってどうしてる?
自分でしか使わないシステムなので、極力西暦で通すか、どうしても必要な場合は1988引いてるけど(基本的に昭和のデータは扱わない)、今度の改元がなぁ >>176
データベースだというのに西暦→和暦マスタテーブルを作ろうという発想がないことに驚く >>176
昭和99年とかの特殊な要件がなければ内部は西暦、外部とのやり取り時に変換が普通かと >>176
表示なり入力なりエンドユーザに一番近いところで変換したいな
そもそも元号という「汚い」ものを可能な限り扱いたくないし、
Postgres用の変換はおそらく自作が必要だが、PHPやJS用なら適当に拾ってこれるから >>177
マスタテーブルだけで変換しようとすると、年の途中での改元に対応しないといけないんで、1日あたり1レコード要るんじゃね?
100年で36,525か36,524になっちゃう >>180
アホくさ。なんで年号が変わらない部分の日の単位でデータを持つんだよ。
それじゃあ自分の生年月日を書くのに今日からさかのぼって一日ごとに列挙して書くようなもんだろw 明治:1868-01-25 〜 1912-07-29
大正:1912-07-30 〜 1926-12-24
昭和:1926-12-25 〜 1989-01-07
平成:1989-01-08 〜
これをどうUIに反映するかは、各自の考え方だろう。 インデックスについて教えてください。
調べましたが「検索が早くなる場合もあるらしい」くらいしか分かりませんでした。
・ インデックスは作成するだけでよいのか?
検索時に作成したインデックスを指定したりしなくてよいのか。
調べた限り指定する方法がなかったため、作成するだけで効果があるように見えた。
・ REINDEXでのロック時の挙動
インデックスがロックされると聞いた。
インデックスがロックされるだけで検索自体は可能なのか。
・ とりあえずインデックスを作成しておけばよいのか?
インデックスがそんなに便利なものなら、ハードディスクの容量が許す限り、
検索しそうなものは片っ端からインデックスを作成しておけばよいのか。 >>186
> ・ インデックスは作成するだけでよいのか?
はい。
インデックスを使った方が検索コストが低い場合は、自動的に使われます。
> ・ REINDEXでのロック時の挙動
> インデックスがロックされるだけで検索自体は可能なのか。
いいえ。検索もブロックされます。
通常はreindexする必要はありません。
将来、reindexが必要だと感じたら(容量が増大したなどの場合)、どう対処するのが
良いか検索するとよいです。
> ・ とりあえずインデックスを作成しておけばよいのか?
いいえ。
インデックスがあるということは、INSERT/DELETEのときにデータ本体だけでなく
インデックスそのものも更新する必要があります。
単純に言えば、処理時間が増えるということです。
不要なインデックスは生成しないようにするのが良いです。 日本語扱うならencodeはCだろって言う人を結構見る気がしますが、なぜutf8じゃ駄目なんでしょうか? 例えばこの人
http://soudai1025.blogspot.jp/2015/03/postgresqlunicode-6.html
> なお、検証した環境のPostgreSQLのlocale指定はC(nolocale)としています。
> (日本語を扱う場合はほとんどの場合はCを指定するでしょうし) えっ・・・
今まで作ったシステム、全部utf8にしてきてしもうた・・・ encodeとlocaleは別だぞ。
encode=utf8 かつ locale=C が推奨なのはよく見る。
Linux (glibc) はlocaleの実装をサボっているので、C以外に設定しても性能が落ちるだけで何の利点もない。
Windowsなら文字列の比較やソートに差が出るので、用途に適して選べばいい。 initdb --encoding=UTF8 --no-locale ←これが基本かなと >>193
Linuxでも当然ながら差が出る。
なぜなら、文字コードは辞書順には並んでないから。 >>196
どんな文字コードでも漢字の並び順は、日本人が見ても意味のある順番になってないからな。 >>196
Linuxもまともになったのか?
昔使ったときはlocale=ja系でも変わらず文字コード順に並べられたんだが >>198
「辞書順」の正しい定義を知らないけど、少なくとも文字コード順には並ばないよ。
create table foo(s text)に、漢数字の'一'から'九'をインサートし、以下のクエリを実行。
select array_agg(s) from (select s from foo order by s) as t;
locale=C -> {一,七,三,九,二,五,八,六,四} -- 文字コード順
locale=ja_JP.UTF-8 -> {一,九,五,三,四,七,二,八,六} -- 辞書(?)順 文字コード順でも辞書順でも、それを正解とするかどうかは要件次第。
ちなみに漢数字は、訓読み順で並んでいる。 >>199
理解した。Linuxでも順序は変わるね。
ひらがな/カタカナの濁/半濁の扱いは今でも差があるようだ。設計思想?互換性?
msvcrt: ハはバばパぱ
glibc : はばぱハバパ
環境依存が怖い。要件次第だが、自前で「ふりがな」列を用意したほうがマシだな。 他人に公開する予定の無い、自分専用のwebサイトを作る場合でもSQLインジェクション対策はしておいた方がいいよね?
クラスを転用するときに問題になるし、悪意が無くてもエラーのもとだし ■ このスレッドは過去ログ倉庫に格納されています