From: mark@mark.mielke.cc
To: Mario Weilguni <mweilguni@sime.com>
Cc: Alexander Staubo <alex@purefiction.net>
Cc: pgsql-performance@postgresql.org, Ruben Rubio <ruben@rentalia.com>
Subject: Re: Optimization of this SQL sentence
Date: Wed, 18 Oct 2006 08:50:09 -0400
Message-ID: <20061018125009.GA10759@mark.mielke.cc> (raw)
In-Reply-To: <200610181131.44840.mweilguni@sime.com>
References: <45349CDF.3090002@rentalia.com>
<200610171729.19596.mweilguni@sime.com>
<EFB9AB5E-C089-4314-BD32-BCEDDFD3EA02@purefiction.net>
<200610181131.44840.mweilguni@sime.com>
On Wed, Oct 18, 2006 at 11:31:44AM +0200, Mario Weilguni wrote:
> It's not a bad idea. Usually I use postal codes with 25 chars, and never had
> any problem. With text, the limit would be ~1 GB. No matter how much testing
> in the application happens, the varchar(25) as last resort is a good idea.
> And in most cases, the application itself limits the length, and thus it's
> good to reflect this in the database design.
> Feel free to use text anywhere for your application, and feel free to use
> numeric(1000) instead of numeric(4) if you want to be prepared for really
> long numbers, but don't tell other people it's bad database design - it
> isn't.
It's unnecessary design.
Suggestions in this regard lead towards the user seeing a database error,
instead of a nice specific message provided by the application.
I used to use varchar instead of text, but have since softened, as the
number of times it has ever actually saved me is zero, and the number of
times it has screwed me up (picking too small of a limit too early) has
been a few.
It's kind of like pre-optimization before there is a problem. Sometimes
it works for you, sometimes it works against.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, mweilguni@sime.com, alex@purefiction.net, ruben@rentalia.com
Subject: Re: Optimization of this SQL sentence
In-Reply-To: <20061018125009.GA10759@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox