Re: Optimization of this SQL sentence

Поиск
Список
Период
Сортировка
От Alexander Staubo
Тема Re: Optimization of this SQL sentence
Дата
Msg-id EFB9AB5E-C089-4314-BD32-BCEDDFD3EA02@purefiction.net
обсуждение исходный текст
Ответ на Optimization of this SQL sentence  (Ruben Rubio <ruben@rentalia.com>)
Ответы Re: Optimization of this SQL sentence  (Mario Weilguni <mweilguni@sime.com>)
Список pgsql-performance
On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:

> Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
>> Lastly, note that in PostgreSQL these length declarations are not
>> necessary:
>>
>>    contacto varchar(255),
>>    fuente varchar(512),
>>    prefijopais varchar(10)
>
> Enforcing length constraints with varchar(xyz) is good database
> design, not a
> bad one. Using text everywhere might be tempting because it works,
> but it's
> not a good idea.

Enforcing length constraints is generally a bad idea because it
assumes you know the data domain as expressed in a quantity of
characters. Off the top of your head, do you know the maximum length
of a zip code? A street address? The name of a city?

In almost all cases the limit you invent is arbitrary, and the
probability of being incompatible with any given input is inversely
proportional to that arbitrary limit.

Encoding specific length constraints in the database makes sense when
they relate explicitly to business logic, but I can think of only a
few cases where it would make sense: restricting the length of
passwords, user names, and so on. In a few cases you do know with
100% certainty the limit of your field, such as with standardized
abbreviations: ISO 3166 country codes, for example. And sometimes you
want to cap data due to storage or transmission costs.

The length constraint on text fields is primarily a historical
artifact stemming from the way databases have traditionally been
implemented, as fixed-length fields in fixed-length row structures.
The inexplicable, improbable space-padded (!) "character" data type
in ANSI SQL is a vestige of this legacy. PostgreSQL's variable-length
rows and TOAST mechanism makes the point moot.

Quoth the PostgreSQL manual, section 8.3:

> There are no performance differences between these three types,
> apart from the increased storage size when using the blank-padded
> type. While character(n) has performance advantages in some other
> database systems, it has no such advantages in PostgreSQL. In most
> situations text or character varying should be used instead.

Alexander.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Alexander Staubo
Дата:
Сообщение: Re: Optimization of this SQL sentence
Следующее
От: Mario Weilguni
Дата:
Сообщение: Re: Optimization of this SQL sentence