Q&A
mingosさん
ご意見ありがとうございます
簡単に試算してみた所
smallintで定義したとてMB単位ほどの軽減しか見込め無さそうです
ご指摘の通り、画像や音声等のバイナリデータを扱う場合
慎重に設計する必要すべきで、この整数程度のそこまで気にしなくてもよさそうですね
サービスのDBはクラウド内にたてていることもあり
料金周り等、少しセンシティブになりすぎていたかもしれません
大変参考になりました
ご回答ありがとうございました
Posgresqlのカラムデータ型の定義について
みなさんの意見を聞かせていただければと思います
自社で運用しているサービスでは
数値を保管するカラムには全てintegerを定義してテーブル作成しています
状態管理のステータスなど数値の上限が予測できるものでもintegerで統一していまして
個人としては新規テーブルではsmallintで定義することでストレージの軽減に繋がるのではと考えています
ここで質問になりますが
皆さんが運用している、または過去に触ったテーブル構造では
整数型を定義する際、integer,smallint,bigintの使い分けはされていましたでしょうか？
また適切に定義することで、ストレージの圧迫に効果は見込めそうでしょうか
回答3件
0
それを言うなら、文字列型も同じです。
postgresは型の違いは結構厳密なので、色々な型を使用する場合、余程しっかりテーブル設計しないと、CASTが必要な場面が多くなります。
使う型によってはレスポンスも違ったりしますので、余程大規模でない限り、基本の属性は数値型はinteger,文字型はtextと考えるのが無難です。
投稿2022/02/19 14:48
総合スコア25426
0
ベストアンサー
現在ストレージの容量はかなり余裕があると思います。
さほど気にする必要がないと思いますが、1レコードあたりの使用容量はデータ型で試算できます。
どの程度のレコード数が常に保存されて、1日あたりどの程度増加するのかという予測を立てれば
おのずと計算できると思います。
ただ、その場合でも数値データを保存するだけであれば、ほとんど心配が必要ないのが現実な気がします。
これが画像データ(BLOB)をDBに保存するといった話ならもっと深刻に設計すべきかなと思うのですが、
たかが数値データであればintegerでいいんじゃないの？というのが個人的な感想です。
投稿2022/02/19 11:48
総合スコア4255
0
最近は単位容量辺りのディスクの価格が下がっているのでギリギリでサイジングすることは少なくなったので、桁あふれでトラブルが起きた時の対応を考えるとあまり神経質にならなくても良いのでは？
気になるようでしたら、既存のいちばんレコード件数が多いテーブルでinteger → smallint に変更した時、PostgreSQL 12.4 数値データ型 で容量がどのくらい減らせるか計算してみては？
投稿2022/02/19 10:50
総合スコア16417
Orlofskyさん
ご意見ありがとうございます
ご意見の通り、万が一の桁溢れのリスク等想定すると
整数の型定義にそこまで気を配らなくてもよさそうですね
smallintにしたとて見込める効果も薄そうですし・
貴重なご意見ありがとうございました
参考にさせていただきます
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。