Re: Drawbacks of using BYTEA for PK? - Mailing list pgsql-general

From Chris Travers
Subject Re: Drawbacks of using BYTEA for PK?
Date
Msg-id 015901c3d9b1$3dc40080$54285e3d@winxp
Whole thread Raw
In response to Re: Drawbacks of using BYTEA for PK?  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-general
Sounds to me you have concerns more along the lines of counterintelligence.

> Maybe a better example of my problem is with records throughout the system
> like invoices, customer data, etc...  If any of these items use a sequence
> and that sequence is global to the table in the database and the number is
> exposed externally, then it is possible to infer the success of the
company
> underneath, is it not?

IMO, the solution here is to start your sequences at an arbitrary value
(preferably not round) such as 1543691.  Therefore the first customer
doesn't know that you don't have 1.5M other customers :-)  This could be
calculated for each sequence with a formula such as
SELECT (random() * 1000000 + 1000000)::bigint;

>
> For instance, if I generate sequential numbers for invoice ids and the
> customer
> sees #123 as an invoice number one month and sees #128 the next month,
> it might
> imply that there are only 4 customers getting invoiced each month.
>
Another solution I have seen is to use a formula for your invoices based on:
Letter key for invoice type followed by YYYYMMDD followed by a numeric
sequence.  This also helps to obscure things since the customer may not know
how often you reset the sequence (could be every month, or every day).  The
letter key can uniquely identify your server on your network thereby
creating a GUID.  In other words your sequence need only be unique to a
given time frame.  You could even add a timestamp and a sequence that wraps
around after 9 :-)  That way as long as you don't create 10 invoices in the
same second you are OK.

>     http://.../account/widget_list.html
>     http://.../account/widget_edit.html?widget_id=12345

Provided that each customer is only creating one widget at a time, you could
then take the customer_id and append to it a value of a customer-specific
sequence.  You could even have this as a compound primary key.  That way,
each customer can only determine how many widgets they have created :-)

> See what I mean?  What do you propose as the best solution for this?

Create GUIDS which contain only the information you want.  No need to hash.
See above for examples.

Best Wishes,
Chris Travers


pgsql-general by date:

Previous
From: "Chris Travers"
Date:
Subject: cryptography, was Drawbacks of using BYTEA for PK?
Next
From: "Chris Travers"
Date:
Subject: Re: what we need to use postgresql in the enterprise