Skip site navigation (1) Skip section navigation (2)

Re: CONSEJO tablas grandes

From: "Guido Barosio" <gbarosio(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Gabriel Ferro" <gabrielrferro(at)yahoo(dot)com(dot)ar>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: CONSEJO tablas grandes
Date: 2008-11-26 02:37:50
Message-ID: f7f6b4c70811251837t3cfccb08i27a6a7ad0e17fc1d@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Que nombre y apellido debian ser una misma columna y debian existir
otras claves a menos que fuese realmente necesario.

Cual es el costo de tener el siguiente esquema?

20.000.000 x columna nombre
+
20.000.000 x columna apellido

Y que tal si es: 20.000.000 x columna nombre_apellido?

A mi, la experiencia me marca que Nombre y Apellido son datos
SELECT'ionables, pero no WHERE'clauseables, asi se dice?

Discusion abierta eh?

gb.-


2008/11/26 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
> Guido Barosio escribió:
>> Alguna vez pensaron que tiende a predominar la busqueda por otras
>> claves distintas a nombres y/o apellidos?
>
> Hmm, no.  ¿En qué casos?  Cuando buscas por DNI (o equivalente) entonces
> usas el índice btree por DNI, y no es necesario el otro, pero ¿qué otra
> clave útil hay para buscar a una persona?
>
>> Dicho eso, se justifica crear dos columnas para un pedazo de
>> informacion que por lo general se consume unificada? ("Nombre,
>> Apellido").
>
> Claro, porque la clave de búsqueda es el apellido.
>
> ¿Y qué decía David?
>
> --
> Alvaro Herrera                http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
> Voy a acabar con todos los humanos / con los humanos yo acabaré
> voy a acabar con todos / con todos los humanos acabaré (Bender)
>

In response to

Responses

pgsql-es-ayuda by date

Next:From: Euler Taveira de OliveiraDate: 2008-11-26 02:41:18
Subject: Re: spanish advocacy mailing list
Previous:From: Diego GilDate: 2008-11-26 02:28:39
Subject: Re: CONSEJO tablas grandes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group