From: | Ruben Rubio <ruben(at)rentalia(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Optimization of this SQL sentence |
Date: | 2006-10-18 07:06:20 |
Message-ID: | 4535D26C.1010404@rentalia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> so, imo alexander is correct:
>> contacto varchar(255)
Why do we have limits on this, for example?
contacto varchar(255)
1) First of all, this is a web application. People use to enter really
strange thinks there, and a lot of rubbish. So, as someone commented
before, I am ok with the idea of limit the field.
2) Again, this is a web application. We could just limit the "field
front end length" but this will be not secure. We could limit the field
front end, and limit it with the code that process the data, but is much
secure if we just limit field in database.
Why 255?
This is free field. We are interested in users enter as much data as
needed (with a limit, we no not want "The Quijote" in that field)
People use to imput as spected:
"Contact: Baltolomé Peralez."
But people also inserts thinks as:
"Contact: In the mornings, Bartolomé Perales, in the afternoons Juan
Perales in the same telephone number"
In the context of the application, we are not interested in stopping the
user with a message "Hey, Your contact is too long". We want the user to
go on. That's why 255. We could insert 260. Or maybe 250. But someone
decided 255 and for me its OK.
Please remember that I just put some data of a large applications, and
there is thinks there that has sense in context.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNdJsIo1XmbAXRboRAuGVAKCupfXOHwxXOPHFdq+K6S0lXWNZUwCgml1i
CS0eEJcQndEJb7h7Nsfh1CM=
=0gpW
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2006-10-18 09:31:44 | Re: Optimization of this SQL sentence |
Previous Message | Tom Lane | 2006-10-18 05:19:39 | Re: Jdbc/postgres performance |