0611NAME IS NULL2021/07/03(土) 17:38:43.26ID:R35jReGz>>609 A5Mk-Uがよく使われている。
0612NAME IS NULL2021/10/13(水) 12:36:34.50ID:??? データベーススペシャリストでよく問われるページサイズとか空き容量率とかどのメーカーのDBをターゲットにしてるんや? 教えてくれ 0613NAME IS NULL2021/10/13(水) 13:54:50.17ID:??? 特にどのDBMSをターゲットにしてるとかないぞ 一般的なBTreeを前提にしてるだけ 0614ド底辺PG2021/11/10(水) 22:00:45.28ID:KaB0M86I プロジェクトが燃え尽きたから別の案件に燃料しに行ったんだが、TEXT(可変長文字列)をPKにしてINDEX張ってて「パフォーマンス出ねぇ!」ってやってんですけど・・・ ちょう乱暴に描くと CREATE TABLE T_TAGS( JPN AS TEXT NOT NULL, ENG AS TEXT, ・・・品詞とか同義語とかの定義いろいろ・・・ PRIMARY KEY(JPN) ) て感じの定義で、SELECTのサブクエリとかでも ON TBL1.JPN = ・・・ みたいにテキストのカラムをJOINしてるんすよ?
ドテ・イ・ヘーンな俺でも「なんで数値でIDのカラムを作らないの?」ぐらいの疑問はあるんだけど、 これって「データベースあるある」だったりするの? 0615NAME IS NULL2021/11/10(水) 22:40:02.10ID:??? 遅いのがTEXTのせいだってどうやって判断したの? 0616NAME IS NULL2021/11/11(木) 00:02:07.19ID:???>>614 >これって「データベースあるある」だったりするの? 文字列をPKに使うかどうかは状況による 絶対避けるというほどのものでもない 個人的には可変長は極力避けるけどパフォーマンスクリティカルなシステムじゃなければ 全部可変長で揃えてても特に問題なかったりする
PKを数値にしたバージョン作ってさくっと比較すればいいんじゃん? 0617NAME IS NULL2021/11/11(木) 19:06:31.16ID:NSxyRLjO>>614 あなたの言っていることは頭がおかしいくらい変なことを言っている。
たまたまいままで見てきたテーブルの主キー項目が数値型だっただけで、根拠のない思い込みをしてないか?
念を押すと、頭のおかしい発言だぞ。 0618NAME IS NULL2021/11/11(木) 19:36:50.37ID:NSxyRLjO>>614 そのTEXT型がラージオブジェクト型というオチのネタ書き込みじゃないだろうな? 0619NAME IS NULL2021/11/11(木) 20:16:55.16ID:???>>617 そこまでやないやろ。w テキストはCOLLATEの懸念があるし、 数値のが望ましいのはたしかやし。