Hello,
We're building a distributed Java/Hibernate/Postgres desktop
application for a small office setting, so we largely remain safely in
our "Java cocoon" without needing to venture into the SQL or Postgres
details too often! We are looking for a few tiny pointers regarding a
few design decisions. Our project is certainly NOT highly optimised,
and does not take Postgress to its limits. The natural speed,
stability, and heritage make Postgres an easy choice for us -
especially since our competitors typically use MS-Access etc.
Question ONE: If we design a field (say) 50 characters long - and we
have an instance/row using only (say) 20 characters - does Postgres
"use" the whole 50, or only the 20??
The issue here is a trade-off in how tightly we need to specify field
lengths that we are currently unsure of. Are we wasting space if we
make them large?
Question TWO: When following typical Hibernate examples we notice that
String fields are typically specified with a length at a "binary
boundary". So they seem to always be specified at 16, 32, 64, 128
etc. Really the question should be "is a String length 17 (or 33 or
65) significantly slower to insert/search/retrieve than a String of
length 16 (or 32 or 64)?".
I cannot imaging any significant performance reason for this in an
"un-optimised" situation like ours. We are not really interested in
marginal or theoretical improvements, just good solid "sensible
postgres practice" improvements.
Any suggestions are appreciated.
Thanks,
-Damian
