[過去ﾛｸﾞ] PostgreSQL Part.11©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
182: 2017/01/29(日)13:32 ID:60pB1fs/(4/4) AAS
>>180
アホくさ。なんで年号が変わらない部分の日の単位でデータを持つんだよ。
それじゃあ自分の生年月日を書くのに今日からさかのぼって一日ごとに列挙して書くようなもんだろw
183: 2017/01/29(日)15:26 ID:??? AAS
明治:1868-01-25 〜 1912-07-29
大正:1912-07-30 〜 1926-12-24
昭和:1926-12-25 〜 1989-01-07
平成:1989-01-08 〜
これをどうＵＩに反映するかは、各自の考え方だろう。
184: 2017/01/30(月)10:51 ID:tcdzx+zX(1) AAS
https://www.youtube.com/watch?v=quIHgwuF6r4&sns=em
185: 2017/02/01(水)10:22 ID:wkr1HydS(1) AAS
https://www.youtube.com/watch?v=quIHgwuF6r4&sns=em
186(2): 2017/02/01(水)14:47 ID:4qKxf55o(1) AAS
インデックスについて教えてください。
調べましたが「検索が早くなる場合もあるらしい」くらいしか分かりませんでした。
・ インデックスは作成するだけでよいのか？
検索時に作成したインデックスを指定したりしなくてよいのか。
調べた限り指定する方法がなかったため、作成するだけで効果があるように見えた。
・ REINDEXでのロック時の挙動
インデックスがロックされると聞いた。
インデックスがロックされるだけで検索自体は可能なのか。
・ とりあえずインデックスを作成しておけばよいのか？
インデックスがそんなに便利なものなら、ハードディスクの容量が許す限り、
省1
187(1): 2017/02/01(水)15:20 ID:??? AAS
>>186
> ・ インデックスは作成するだけでよいのか？
はい。
インデックスを使った方が検索コストが低い場合は、自動的に使われます。
> ・ REINDEXでのロック時の挙動
> インデックスがロックされるだけで検索自体は可能なのか。
いいえ。検索もブロックされます。
通常はreindexする必要はありません。
将来、reindexが必要だと感じたら（容量が増大したなどの場合）、どう対処するのが
良いか検索するとよいです。
省6
188: 186 2017/02/01(水)15:43 ID:??? AAS
>187
ありがとうございます。
助かります。
189: 2017/02/01(水)18:30 ID:ndjPxyEX(1) AAS
ポスグレにかぎらない初心者の質問が多いな。
190(1): 2017/02/02(木)17:57 ID:??? AAS
日本語扱うならencodeはCだろって言う人を結構見る気がしますが、なぜutf8じゃ駄目なんでしょうか？
191: 190 2017/02/02(木)18:00 ID:??? AAS
例えばこの人
http://soudai1025.blogspot.jp/2015/03/postgresqlunicode-6.html
> なお、検証した環境のPostgreSQLのlocale指定はC（nolocale)としています。
> （日本語を扱う場合はほとんどの場合はCを指定するでしょうし）
192: 2017/02/02(木)18:41 ID:??? AAS
えっ・・・
今まで作ったシステム、全部utf8にしてきてしもうた・・・
193(1): 2017/02/02(木)19:10 ID:??? AAS
encodeとlocaleは別だぞ。
encode=utf8 かつ locale=C が推奨なのはよく見る。
Linux (glibc) はlocaleの実装をサボっているので、C以外に設定しても性能が落ちるだけで何の利点もない。
Windowsなら文字列の比較やソートに差が出るので、用途に適して選べばいい。
194: 2017/02/02(木)22:45 ID:??? AAS
initdb --encoding=UTF8 --no-locale ←これが基本かなと
195: 2017/02/03(金)08:35 ID:kkoWZhIO(1) AAS
https://www.youtube.com/watch?v=quIHgwuF6r4&sns=em
196(2): 2017/02/03(金)14:49 ID:??? AAS
>>193
Linuxでも当然ながら差が出る。
なぜなら、文字コードは辞書順には並んでないから。
197: 2017/02/03(金)15:00 ID:JY8XYZfi(1) AAS
>>196
どんな文字コードでも漢字の並び順は、日本人が見ても意味のある順番になってないからな。
198(1): 2017/02/03(金)15:45 ID:??? AAS
>>196
Linuxもまともになったのか？
昔使ったときはlocale=ja系でも変わらず文字コード順に並べられたんだが
199(1): 2017/02/03(金)16:06 ID:??? AAS
>>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 -> {一,九,五,三,四,七,二,八,六} -- 辞書(?)順
200: 2017/02/03(金)16:35 ID:??? AAS
文字コード順でも辞書順でも、それを正解とするかどうかは要件次第。
ちなみに漢数字は、訓読み順で並んでいる。
201: 2017/02/03(金)16:45 ID:??? AAS
>>199
理解した。Linuxでも順序は変わるね。
ひらがな／カタカナの濁／半濁の扱いは今でも差があるようだ。設計思想？互換性？
msvcrt: ハはバばパぱ
glibc : はばぱハバパ
環境依存が怖い。要件次第だが、自前で「ふりがな」列を用意したほうがマシだな。
上下前次1-新書関写板覧索設栞歴
あと 801 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.012s