on 7/20/04 11:05 PM, Michael Stassen at [EMAIL PROTECTED] wrote:
> What is user_id? You didn't mention it before. Will the user with
> user_id=123 be able to make a 'work' group and the user with user_id=456
> also be able to make a 'work' group? That is, you have multiple lists
> (group) for e
> > Yeah, exactly. The ON DUPLICATE KEY is useful if
> your table has
> > something like a "last modified" or "last
> accessed" column that is
> > relevant for what you're doing. It is just an
> easier way to accomplish
> > INSERT IGNORE plus then doing an UPDATE on all the
> rows that got
> > ign
Scott Haneda wrote:
I will also have one more case that needs this treatment as well, say there
are 2 groups of emails, lets call them "family" and work". I will be
allowing the user to merge those into one group, something like:
UPDATE addresses SET group='family' WHERE group='work' AND user_id
I'd suggest turning those around:
ALTER TABLE tablename ADD UNIQUE `index_name` (group, email_address)
Why? For purposes of keeping the combination of group and email unique, the
order doesn't matter, but the leftmost part of the index can be used just as
if it were a single column index. Fro
on 7/20/04 10:06 PM, Wesley Furgiuele at [EMAIL PROTECTED] wrote:
> Scott:
>
> Yeah, exactly. The ON DUPLICATE KEY is useful if your table has
> something like a "last modified" or "last accessed" column that is
> relevant for what you're doing. It is just an easier way to accomplish
> INSERT IGN
Scott:
Yeah, exactly. The ON DUPLICATE KEY is useful if your table has
something like a "last modified" or "last accessed" column that is
relevant for what you're doing. It is just an easier way to accomplish
INSERT IGNORE plus then doing an UPDATE on all the rows that got
ignored, in case you
on 7/20/04 9:44 PM, Wesley Furgiuele at [EMAIL PROTECTED] wrote:
> First off, the unique index is something you define for the table once.
> Being unique, you won't be allowed to add in another record with the
> same values as an record that already exists in the table.
I thought so, thanks.
> A
First off, the unique index is something you define for the table once.
Being unique, you won't be allowed to add in another record with the
same values as an record that already exists in the table.
And yes, once you set it up, INSERT IGNORE would allow your query to
simply skip the insertion
on 7/20/04 4:10 PM, Wesley Furgiuele at [EMAIL PROTECTED] wrote:
> Rather than make the email address column unique, since you want to
> allow multiple email address instances, you can make a unique index
> based on email_address+group. Wouldn't that help, or is that still too
> simple for your si
Scott:
Sorry, should have included it...
http://dev.mysql.com/doc/mysql/en/CREATE_INDEX.html
The basic syntax you're looking to use is
ALTER TABLE tablename ADD UNIQUE `index_name` ( email_address, group )
Wes
On Jul 20, 2004, at 7:45 PM, Scott Haneda wrote:
on 7/20/04 4:10 PM, Wesley Furgiuele at
on 7/20/04 4:10 PM, Wesley Furgiuele at [EMAIL PROTECTED] wrote:
> Rather than make the email address column unique, since you want to allow
> multiple email address instances, you can make a unique index based on
> email_address+group. Wouldn't that help, or is that still too simple for your
> si
Scott:
Rather than make the email address column unique, since you want to
allow multiple email address instances, you can make a unique index
based on email_address+group. Wouldn't that help, or is that still too
simple for your situation?
Regarding temporary tables, from the MySQL manual:
Fro
12 matches
Mail list logo
