Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
This could hurt if they ever reuse an old previously retired postal code,
which isn't an entirely impossible case. As far as I know it hasn't happened
yet though.
One would suppose that the guys who are in charge
On 24 Nov 2004 01:52:52 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Alexandre Leclerc [EMAIL PROTECTED] writes:
Thanks for those tips. I'll print and keep them. So in my case, the
product_code being varchar(24) is:
4 bytes + string size (so possibly up to 24) = possible 28 bytes. I
did
On Mon, 22 Nov 2004 16:54:56 -0800, Josh Berkus [EMAIL PROTECTED] wrote:
Alexandre,
What is the common approach? Should I use directly the product_code as
my ID, or use a sequantial number for speed? (I did the same for the
company_id, this is a 'serial' and not the shor name of the
All,
Well, you should still escape any strings you're getting from a web
page so
you can ensure you're not subject to a SQL insert attack, even if you're
expecting integers.
Thanks,
Peter Darley
Well, your framework should do this for you :
integer specified in your database object class
Alexandre Leclerc [EMAIL PROTECTED] writes:
Thanks for those tips. I'll print and keep them. So in my case, the
product_code being varchar(24) is:
4 bytes + string size (so possibly up to 24) = possible 28 bytes. I
did the good thing using a serial. For my shorter keys (4 bytes + up
to 6
Good day,
I'm asking myself if there is a performance issue in using an integer
of varchar(24) PRIMARY KEY in a product table.
I've read that there is no speed issue in the query, but that the only
performance issue is the database size of copying the key in other
tables that require it.
My
What is the common approach? Should I use directly the product_code as
my ID, or use a sequantial number for speed? (I did the same for the
company_id, this is a 'serial' and not the shor name of the customer.
I just don't know what is usually done.
Use a serial :
- you can change product_code
Mr Caillaud,
Merci! Many points you bring were also my toughts. I was asking myself
really this was the way to go. I'm happy to see that my view of the
problem was good.
Encore merci! (Thanks again!)
On Tue, 23 Nov 2004 00:06:13 +0100, Pierre-Frédéric Caillaud
[EMAIL PROTECTED] wrote:
What
Alexandre,
What is the common approach? Should I use directly the product_code as
my ID, or use a sequantial number for speed? (I did the same for the
company_id, this is a 'serial' and not the shor name of the customer.
I just don't know what is usually done.
Don't use SERIAL just because
On Mon, 2004-11-22 at 16:54 -0800, Josh Berkus wrote:
Alexandre,
What is the common approach? Should I use directly the product_code as
my ID, or use a sequantial number for speed? (I did the same for the
company_id, this is a 'serial' and not the shor name of the customer.
I just don't
Rod,
It would be nice if PostgreSQL had some form of transparent surrogate
keying in the background which would automatically run around and
replace your real data with SERIAL integers. It could use a lookup table
for conversions between the surrogate and real values so the user never
knows
11 matches
Mail list logo
