>
>
> I read it that he has multiple sales from the same person? In which case
> pretending that the two sales were from different people isn't the correct
> result at all.
Actually it turns out that both cases exist.
>
> I may be missing the point of the query, but wasn't it to add an entry for
On 11 February 2013 07:47, Alban Hertroys wrote:
> On Feb 11, 2013, at 2:23, Tim Uckun wrote:
>
> > This works pretty good except for when the top 100 records have
> > duplicated email address (two sales for the same email address).
> >
> > I am wondering what the best strategy is for dealing wi
> The best strategy is fixing your data-model so that you have a unique key. As
> you found out already, e-mail addresses aren't very suitable as unique keys
> for people. For this particular case I'd suggest adding a surrogate key.
>
> Alternatively, you might try using (first_name, email) as yo
On Feb 11, 2013, at 2:23, Tim Uckun wrote:
> This works pretty good except for when the top 100 records have
> duplicated email address (two sales for the same email address).
>
> I am wondering what the best strategy is for dealing with this
> scenario. Doing the records one at a time would wo
On Sun, Feb 10, 2013 at 5:23 PM, Tim Uckun wrote:
> This works pretty good except for when the top 100 records have
> duplicated email address (two sales for the same email address).
How is it assumed to work when the migrating email already exists in people?
>
> I am wondering what the best str
I am using a query like this to try and normalize a table.
WITH nd as (select * from sales order by id limit 100),
people_update as (update people p set first_name = nd.first_name from
nd where p.email = nd.email returning nd.id),
insert into people (first_name, email, created_at, updated_at)
