ssage-
> From: Mark Goodge [mailto:m...@good-stuff.co.uk]
> Sent: Monday, July 16, 2012 10:13 AM
> To: Mysql General List
> Subject: Re: Unique index - opinions sought
>
> On 16/07/2012 17:39, Rick James wrote:
> > How many rows? If 1K, it does not matter. If 1
On 16/07/2012 17:39, Rick James wrote:
How many rows? If 1K, it does not matter. If 1 billion, we need to
discuss in more detail. Let's assume 1M...
Around 1M in the item_spine table and 10M in item_detail.
Dates should be stored in DATE datatype, which is 3 bytes. Your GUID
is non-standa
How many rows? If 1K, it does not matter. If 1 billion, we need to discuss
in more detail. Let's assume 1M...
Dates should be stored in DATE datatype, which is 3 bytes.
Your GUID is non-standard, but should probably be stored in CHAR(6) CHARACTER
SET ascii, unless it is expected to have non-
Hi,
On 17-10-2011 15:39, Peng Yu wrote:
If I use "NULL UNIQUE" when I create a table, it seems that only one
NULL entry is allowed. Since NULL could mean unknown, in this case,
two unknowns are not the same and I want to allow multiple nulls but I
still want non null entries be unique. Is there
I may have missed what you are trying to do here. NoSQL is really a bad name
and should really be renamed to NoREL instead. NoSQL implementations are not
used just because of limitations of traditional RDBMS when it comes to sheer
traffic volume, they are also used because they scale horizontally v
On Mon, Sep 13, 2010 at 8:59 PM, Johnny Withers wrote:
>
> This sounds like a good job for a 'NoSQL' system. Maybe?
>
I can't help but blink at that. How exactly is NoSQL going to fix issues
that are related to topology, not inherent SQL limitations ? Which
particular incarnation of NoSQL are you
On Mon, September 13, 2010 15:37, Daevid Vincent wrote:
>>
-Original Message-
>>
From: Kiss D�niel
[mailto:n...@dinagon.com]
>> Sent: Monday, September 13, 2010
5:59 AM
>>
>> Well, thanks, but I'm afraid using
UUID's (even with hex
>> compression) is
>> kind of
a suicide, when it comes to
> -Original Message-
> From: Kiss Dániel [mailto:n...@dinagon.com]
> Sent: Monday, September 13, 2010 5:59 AM
>
> Well, thanks, but I'm afraid using UUID's (even with hex
> compression) is
> kind of a suicide, when it comes to performance.
> This is a good summary about the issues:
> http
From: Kiss Dániel [mailto:n...@dinagon.com]
Sent: Monday, September 13, 2010 3:17 PM
To: Jerry Schwartz
Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
replicat...@lists.mysql.com
Subject: Re: Unique ID's across multiple databases
Well, that would be the plan, yes. :-)
Anyway,
M
> >To: Jerry Schwartz
> >Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
> >replicat...@lists.mysql.com
> >Subject: Re: Unique ID's across multiple databases
> >
> >Well, not exactly.
> >
> >I do not own all the databases. Some o
artz
> >Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
> >replicat...@lists.mysql.com
> >Subject: Re: Unique ID's across multiple databases
> >
> >Well, not exactly.
> >
> >I do not own all the databases. Some of them are placed at customers
>-Original Message-
>From: Kiss Dániel [mailto:n...@dinagon.com]
>Sent: Monday, September 13, 2010 11:49 AM
>To: Jerry Schwartz
>Cc: Johan De Meersman; Max Schubert; mysql@lists.mysql.com;
>replicat...@lists.mysql.com
>Subject: Re: Unique ID's across multiple data
;From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan
> De
> >Meersman
> >Sent: Monday, September 13, 2010 7:27 AM
> >To: Kiss Dániel
> >Cc: Max Schubert; mysql@lists.mysql.com; replicat...@lists.mysql.com
> >Subject: Re: Unique ID's across multip
>-Original Message-
>From: vegiv...@gmail.com [mailto:vegiv...@gmail.com] On Behalf Of Johan De
>Meersman
>Sent: Monday, September 13, 2010 7:27 AM
>To: Kiss Dániel
>Cc: Max Schubert; mysql@lists.mysql.com; replicat...@lists.mysql.com
>Subject: Re: Unique ID's
>-Original Message-
>From: Kiss Dániel [mailto:n...@dinagon.com]
>Sent: Sunday, September 12, 2010 1:47 PM
>To: mysql@lists.mysql.com; replicat...@lists.mysql.com
>Subject: Unique ID's across multiple databases
>
>Hi,
>
>I'm designing a master-to-master replication architecture.
>I wonder w
Well, thanks, but I'm afraid using UUID's (even with hex compression) is
kind of a suicide, when it comes to performance.
This is a good summary about the issues:
http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
So, some kind of auto_increment or sequencing must be the optima
Hell, yeah. :)
Actually, the ID system I described below works quite well according to my
tests. I feel very comfortable with it both from primary key size and
dynamically increasable database number point of views.
What I actually don't like in it is the concatenated unique ID (ID + SID)
pairs. T
I had some coffee and realized that actually, using a UUID might be
something to look at. There have been quite a few discussions about using a
UUID as a unique id and it does have some gotchas. Just Google: mysql uuid
Have a great day
~~Fish~~
On Mon, Sep 13, 2010 at 7:30 AM, Fish Kungfu
I could be way off here, but how about letting your unique id be a
calculated column of the the server's MAC address concatenated with an
auto-increment id column?
I hope this helps...
~~Fish~~
On Mon, Sep 13, 2010 at 7:26 AM, Johan De Meersman wrote:
> Hmm, that's a very interesting scenario,
Hmm, that's a very interesting scenario, indeed.
One bad connection will break the chain, though, so in effect you'll be
multiplying the disconnecting rate...
I think you'd be better of with a star topology, but MySQL unfortunately
only allows ring-types. This is gonna require some good thinking
This is actually more for failover scenarios where databases are spread in
multiple locations with unreliable internet connections. But you want to
keep every single location working even when they are cut off from the other
databases. The primary purpose is not load distribution.
On Mon, Sep 13,
On Sun, Sep 12, 2010 at 9:45 PM, Kiss Dániel wrote:
> offset + increment thingy is good if you know in advance that you'll have a
> limited number of servers. But if you have no idea that you will have 2,
> 20,
> or 200 servers in your array in the future, you just can't pick an optimal
>
What b
You may be right. I'm not arguing that offset + increment is working.
I'm just wondering if that's the optimal solution when you do not know how
many servers you will have in your array in the future. In my view, the
offset + increment thingy is good if you know in advance that you'll have a
limit
Server offset + increment works really well, is simple, and well
documented and reliable - not sure why you would want to re-invent
something that works so well :).
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=
On 12 Sep 2010, at 19:47, Kiss Dániel wrote:
> - SID adds only 2 bytes in this case to the size of the primary key item.
> It can be even 1 byte if I'm sure I'll never exceed maximum 255 servers. But
> anyhow, it is still way smaller than the 16 byte of a UUID field, even if
> using BIGINT's
On 07/30/2009 02:23 PM, Joerg Bruehe wrote:
Hi !
mos wrote:
At 09:13 AM 7/30/2009, b wrote:
Are UNIQUE KEY& UNIQUE INDEX two ways of specifying the same thing?
If not, what are the differences?
Feel free to tell me to RTFM but please post manual chapters. I've
been looking but haven't been a
Hi !
mos wrote:
> At 09:13 AM 7/30/2009, b wrote:
>> Are UNIQUE KEY & UNIQUE INDEX two ways of specifying the same thing?
>> If not, what are the differences?
>>
>> Feel free to tell me to RTFM but please post manual chapters. I've
>> been looking but haven't been able to find anything.
>
> They
At 09:13 AM 7/30/2009, b wrote:
Are UNIQUE KEY & UNIQUE INDEX two ways of specifying the same thing? If
not, what are the differences?
Feel free to tell me to RTFM but please post manual chapters. I've been
looking but haven't been able to find anything.
They are the same thing. If you mean
> Why would the auto_increment not work for you? The only case where you
> would have a problem is if the last record was deleted before mysql
> shutdown. If you are really concerned about this unique scenario,
> insert a dummy record before shutdown to guard against it and delete
> the dummy reco
> >I try to generate a unique id for each row in a Mysql-InnoDB Table.
> >Because of many deletes I can't use an auto_increment column.
> >After a Mysql restart, the next value for an auto_increment-column is
> >max(auto_increment-column)+1, and I need a really unique id.
> >
> [JS] See if the
rom: Jerry Schwartz <[EMAIL PROTECTED]>
>Sent: Aug 12, 2008 9:46 AM
>To: [EMAIL PROTECTED], mysql@lists.mysql.com
>Subject: RE: Unique Id generation
>
>>I try to generate a unique id for each row in a Mysql-InnoDB Table.
>>Because of many deletes I can't use an
Why would the auto_increment not work for you? The only case where you
would have a problem is if the last record was deleted before mysql
shutdown. If you are really concerned about this unique scenario,
insert a dummy record before shutdown to guard against it and delete
the dummy record after yo
>I try to generate a unique id for each row in a Mysql-InnoDB Table.
>Because of many deletes I can't use an auto_increment column.
>After a Mysql restart, the next value for an auto_increment-column is
>max(auto_increment-column)+1, and I need a really unique id.
>
[JS] See if the UUID() functio
On 7/19/07, John Comerford <[EMAIL PROTECTED]> wrote:
I am in the process of putting together a web application. I have
decided to add a 'RowId' field to all my tables and assign it a unique
number so that I use it to retrieve data. In concept this number might
be passed back to the server as p
There is a general concern if the user can manipulate variables so that they
pose a threat to your app...
On 7/19/07 12:56 AM, "John Comerford" <[EMAIL PROTECTED]> wrote:
> Hi Folks,
>
> I am in the process of putting together a web application. I have
> decided to add a 'RowId' field to all m
> From: Dan Buettner [mailto:[EMAIL PROTECTED]
> This is a feature - a NULL value is an undefined value,
> therefore two NULL values are not the same. Can be a little
> confusing but makes sense when you think about it.
>
> A UNIQUE index does ensure that non-NULL values are unique;
> you co
> I have an InnoDB table similar to this:
>
> CREATE TABLE Target
> (IMSI VARCHAR(15) ASCII,
> IMEI VARCHAR(15) ASCII,
> UNIQUE KEY (IMSI, IMEI));
>
> After playing a bit with it, I managed to add duplicate records, if one of
> the fields was a NULL:
>
> +-+-+
> |
This is a feature - a NULL value is an undefined value, therefore two
NULL values are not the same. Can be a little confusing but makes
sense when you think about it.
A UNIQUE index does ensure that non-NULL values are unique; you could
specify that your column not accept NULL values.
Dan
On
It is expected behavior, you can make the unique key a primary key
instead. This should prevent this situation.
Ed
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, December 11, 2006 7:42 AM
To: mysql@lists.mysql.com
Subject: UNIQUE KEY vs NULLs
Hi,
I
> I have this SQL statement:
>
> CREATE TABLE rooms (
> idSERIAL,
> room_name TEXT UNIQUE,
> location TEXT,
> last_updated TIMESTAMP DEFAULT
> CURRENT_TIMESTAMP NOT NULL
In article <[EMAIL PROTECTED]>,
Ferindo Middleton Jr <[EMAIL PROTECTED]> writes:
> I have this SQL statement:
> CREATE TABLE rooms (
> idSERIAL,
> room_name TEXT UNIQUE,
> location TEXT,
>
At 22:49 -0500 11/21/05, Ferindo Middleton Jr wrote:
I have this SQL statement:
CREATE TABLE rooms (
idSERIAL,
room_name TEXT UNIQUE,
location TEXT,
last_updated TIMESTAMP
[EMAIL PROTECTED] wrote:
"Michael J. Pawlowsky" <[EMAIL PROTECTED]> wrote on 10/28/2005 11:28:42
AM:
When creating an index in phpMySQL I get a warning message about having
2 indexes using the same field.
The table is simply a product comment table.
The first index is simply an INDEX on
"Michael J. Pawlowsky" <[EMAIL PROTECTED]> wrote on 10/28/2005 11:28:42
AM:
>
> When creating an index in phpMySQL I get a warning message about having
> 2 indexes using the same field.
>
> The table is simply a product comment table.
>
> The first index is simply an INDEX on the product_id to
Hello.
It works for me on MySQL 5.0.10:
mysql> CREATE TABLE `manager_new` (
-> `id` bigint(20) NOT NULL auto_increment,
-> `id_from_hits` bigint(20) default NULL,
-> `from_ip` varchar(15) default NULL,
-> `pool` char(1) NOT NULL default 'n',
-> `to_ip` varcha
Seth Leonard <[EMAIL PROTECTED]> wrote on 07/01/2005 04:43:05 PM:
>
> I constantly bump up against this issue and am looking for a good
> solution. I want a query that will return multiple rows, but only one
> row per unique identifier in one field.
>
>
>
> For instance, if I have the followi
> From: "Dennis Fogg"
> > I'm getting lots of duplicate rows even though I have a
> > unique index defined over multiple columns.
> > The issue is that multiple NULL values are allowed,
> > even when some values are not null.
> > This could be as specified by the SQL standard,
> > but it's certai
From: "Dennis Fogg"
> I'm getting lots of duplicate rows even though I have a
> unique index defined over multiple columns.
> The issue is that multiple NULL values are allowed,
> even when some values are not null.
> This could be as specified by the SQL standard,
> but it's certainly confusing fo
I think you should review the very recent thread "why NOT NULL in
PRIMARY key??" which might shed some light on your particular issue.
In a nutshell, NULL!=NULL, so the database engine can not detect the
duplicate rows, as is expected.
-Hank
On 5/4/05, Dennis Fogg <[EMAIL PROTECTED]> wrote:
> I'
On 4/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/21/2005 01:39:15
> PM:
> > On 4/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005
> > 05:46:25 PM:
> > > > On 4/20/05, [EMAIL
Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/21/2005 01:39:15
PM:
> On 4/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005
> 05:46:25 PM:
> > > On 4/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Willie Gnarlson <[E
On 4/21/05, Willie Gnarlson <[EMAIL PROTECTED]> wrote:
(...)
> It actually seems slower. The separate tables from a previous try look
> like this:
>
> CREATE TABLE `ET` (
> `ET` double NOT NULL default '0',
> PRIMARY KEY (`ET`),
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
>
> That table has
On 4/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005 05:46:25 PM:
> > On 4/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005
> 01:56:03 PM:
> > > > On 4/20/05, Dan Nels
Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005 05:46:25
PM:
> On 4/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005
01:56:03 PM:
> > > On 4/20/05, Dan Nelson <[EMAIL PROTECTED]> wrote:
> > > > In the last episode (Apr 20),
On 4/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005 01:56:03 PM:
> > On 4/20/05, Dan Nelson <[EMAIL PROTECTED]> wrote:
> > > In the last episode (Apr 20), Willie Gnarlson said:
> > > > I have been attempting to uncover a fast method
Willie Gnarlson <[EMAIL PROTECTED]> wrote on 04/20/2005 01:56:03
PM:
> On 4/20/05, Dan Nelson <[EMAIL PROTECTED]> wrote:
> > In the last episode (Apr 20), Willie Gnarlson said:
> > > I have been attempting to uncover a fast method for retrieving
unique
> > > items from every column in a table. T
On 4/20/05, Dan Nelson <[EMAIL PROTECTED]> wrote:
> In the last episode (Apr 20), Willie Gnarlson said:
> > I have been attempting to uncover a fast method for retrieving unique
> > items from every column in a table. The table has approximately 60
> > thousand rows. Each row has an index associate
In the last episode (Apr 20), Willie Gnarlson said:
> I have been attempting to uncover a fast method for retrieving unique
> items from every column in a table. The table has approximately 60
> thousand rows. Each row has an index associated with it, and running
> 'explain select distinct class fr
In article <[EMAIL PROTECTED]>,
"Gustafson, Tim" <[EMAIL PROTECTED]> writes:
> Martijn,
> The problem is that I don't want more than one row in the table that has
> a null value in the column. As you've pointed out in your e-mail,
> there's a difference between NULL and BLANK. It's not that I do
Tim,
> The table in question is used to store aliases to web sites. That is,
> "meitech.com" is the main web site, and "www.meitech.com" is the alias.
> So, the first column is the domain name in question, and the second on
> is the host name part of the alias, in this example "www".
>
> Now, I a
> The problem is that I don't want more than one row in the table that has
> a null value in the column. As you've pointed out in your e-mail,
> there's a difference between NULL and BLANK. It's not that I don't want
> NULL values, it's that I don't want MORE THAN ONE.
I can easily continue arg
Gustafson, Tim; Paul DuBois; mysql@lists.mysql.com
Subject: Re: UNIQUE Key Allowing Duplicate NULL Values
Tim,
> Oh well, thanks anyhow.
>
> If I could put in a feature suggestion, it would be a flag that I
could
> set to disallow duplicate nulls. :)
What for?
NULL is not equal to N
Tim,
> Oh well, thanks anyhow.
>
> If I could put in a feature suggestion, it would be a flag that I could
> set to disallow duplicate nulls. :)
What for?
NULL is not equal to NULL. Period.
If you don't want NULLs, make the column "not null".
The specification is correct.
With regards,
Mart
/
-Original Message-
From: Paul DuBois [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 8:14 AM
To: Gustafson, Tim; mysql@lists.mysql.com
Subject: RE: UNIQUE Key Allowing Duplicate NULL Values
At 8:10 -0500 2/23/05, Gustafson, Tim wrote:
>Is there any flag I can set on
x27;d have to use a BDB table, because only BDB allows a single
NULL per UNIQUE index.
-Original Message-
From: Paul DuBois [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 22, 2005 3:13 PM
To: Gustafson, Tim; mysql@lists.mysql.com
Subject: Re: UNIQUE Key Allowing Duplicate NULL Values
At
:[EMAIL PROTECTED]
Sent: Tuesday, February 22, 2005 3:13 PM
To: Gustafson, Tim; mysql@lists.mysql.com
Subject: Re: UNIQUE Key Allowing Duplicate NULL Values
At 15:00 -0500 2/22/05, Gustafson, Tim wrote:
>Hi there!
>
>I have a table, defined as follows:
>
>CREATE TABLE `Web
At 15:00 -0500 2/22/05, Gustafson, Tim wrote:
Hi there!
I have a table, defined as follows:
CREATE TABLE `WebSiteDomainNames` (
`ID` int(10) unsigned NOT NULL auto_increment,
`WebSite` int(10) unsigned NOT NULL default '0',
`DomainName` int(10) unsigned NOT NULL default '0',
`Alias` char(16
When I saw this message a few weeks ago, I *knew* MySQL had something for
this, but I couldn't remember where I saw it, and I couldn't find it. Today
I found it.
Take a look at: http://dev.mysql.com/doc/mysql/en/Miscellaneous_functions.html
and scroll down to UUID()
Returns a Universal Unique
Hello,
> RE:
> > And columns in primary keys must be NOT NULL. Columns in unique
> > keys can be NULL (if they are NOT NULL, then the unique key is
> > functionally the same as a primary key).
>
> OK, thanks guys for the explanation.
>
> Then the result of mysqldump table definition part:
>
> UNI
> >> I have two tables, seemigly very similar setup; the primary key is the
> >> combination of two columns. With mysqldump, however, the table
> >> definition of the two tables looks different.
> >>
> >> Mysqldump on table 1 says
> >> ...
> >> UNIQUE KEY HONstid (HONstid,HONname)
>
Hi,
RE:
> And columns in primary keys must be NOT NULL. Columns in unique
> keys can be NULL (if they are NOT NULL, then the unique key is
> functionally the same as a primary key).
OK, thanks guys for the explanation.
Then the result of mysqldump table definition part:
UNIQUE KEY HONstid (HON
At 22:27 +0100 12/28/04, Martijn Tonies wrote:
Hello,
I have two tables, seemigly very similar setup; the primary key is the
combination of two columns. With mysqldump, however, the table
definition of the two tables looks different.
Mysqldump on table 1 says
...
UNIQUE KEY HONstid (H
Hello,
> I have two tables, seemigly very similar setup; the primary key is the
> combination of two columns. With mysqldump, however, the table
> definition of the two tables looks different.
>
> Mysqldump on table 1 says
> ...
> UNIQUE KEY HONstid (HONstid,HONname)
> whereas on table 2 i
with implicit join :
INSERT into table1(id, list of other columns)
select m.newID, list of other columns from table2, tmpIDMAP
where
m.id = table2.id
UPDATE table3, tmpIDMAP
SET table3.parentID = m.newID
where
m.id = table3.parentID
Andrew Mull wrote:
Thank you. I'll have to review the SQL care
Thank you. I'll have to review the SQL carefully as I haven't used inner
joins in quite some time :)
Quoting [EMAIL PROTECTED]:
> Create a temporary table that will act as a map between your old IDs and
> your new ones. That way you can re-use those values and change them from
> the old val
Create a temporary table that will act as a map between your old IDs and
your new ones. That way you can re-use those values and change them from
the old values to the new values.
LOCK TABLE table1 WRITE, table2 WRITE, table3 WRITE;
select @max_id:=max(id) FROM table1;
CREATE TEMPORARY TABLE
You are correct in that I need to merge two tables. However, I'm not clear on
how to update the FKs in the sub tables.
Example, the main table (Person) has a sub table (Address). Person has a 1:N
relationship with Address. So Address has the Person's ID as a FK. How do I
update the FK in
Andrew Mull wrote:
I'm working on a rather large database with many cross-linked tables
currently using auto increment IDs. The system is primarily a web based
system, however, there will be times that the system will be run as a stand
alone server...meaning no internet connection is available.
ALTER TABLE tablename ADD UNIQUE (Column1, Column2);
Best Regards,
Andrew
> Can someone explain how I can make a combination of two fields be a
> unique index.
>
> For example, in my table I have an OrderID field and a LineItems field.
> Individually the fields are not unique but when combined t
BINARY is for CHAR and VARCHAR, but he's using TINYTEXT. The binary version
of TINYTEXT is TINYBLOB.
Michael
mos wrote:
Paul,
Just use the "Binary" column attribute to make it case sensitive..
From MySQL Manual: http://dev.mysql.com/doc/mysql/en/CHAR.html
As of MySQL 4.1, values in CHAR
BT> Hello again,
BT> I have a form that users fill out and submit into a mysql database using php.
BT> The problem I have is that there is only one unique field in the main
BT> table... it's an int that's auto-incremented with each new entry. This works
BT> fine unless the user accidentally sub
At 20:41 -0400 4/7/04, Brad Tilley wrote:
Hello again,
How do you make a field unique, but not have it as part of the primary key?
For example, I have a 'computers' table that has a 'comp_id' field that's the
primary key. It's an int that's auto-incremented with each new entry. The
same table has
Brad Tilley wrote:
Hello again,
How do you make a field unique, but not have it as part of the primary key?
For example, I have a 'computers' table that has a 'comp_id' field that's the
primary key. It's an int that's auto-incremented with each new entry. The
same table has a 'comp_serial' fie
Hi Scott,
> Is there any way to define a column in MySql 4 that is to be unique from
> this point forward. Meaning, there are indeed dupes in the column now,
> those are ok, there is really no repairing that damage as the data was
> inherited from somewhere else. I am constantly having to selec
Hi,
Could you just break out the email information into its own table? Then
you could have columns like the following:
UserID (foreign key), email (varchar), type (int: 1=primary email,
2=alias email).
Then you can just have the email column defined as a unique index and
relate the email to the
Anand Buddhdev wrote:
On Fri, Feb 27, 2004 at 12:58:14PM +0200, Egor Egorov wrote:
I'm using mysql version 3.23.58, on Fedora core 1 (the default
supplied on the system).
I have searched the mailing list archives, and google, for my query,
but have not yet found an answer.
Does anyone know if it
On Fri, Feb 27, 2004 at 01:54:13PM +0200, Egor Egorov wrote:
> > Ok, thanks for the response.
> >
> > The problem with first doing a select, and then an insert, is that
> > there exists a race condition. Between the select and insert, someone
> > else could insert a row which might cause a duplic
Anand Buddhdev <[EMAIL PROTECTED]> wrote on 27/02/2004 11:26:41:
> The problem with first doing a select, and then an insert, is that
> there exists a race condition. Between the select and insert, someone
> else could insert a row which might cause a duplication.
>
> I have another soluti
Anand Buddhdev <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 27, 2004 at 12:58:14PM +0200, Egor Egorov wrote:
>
>> > I'm using mysql version 3.23.58, on Fedora core 1 (the default
>> > supplied on the system).
>> >
>> > I have searched the mailing list archives, and google, for my query,
>> > but have
On Fri, Feb 27, 2004 at 12:58:14PM +0200, Egor Egorov wrote:
> > I'm using mysql version 3.23.58, on Fedora core 1 (the default
> > supplied on the system).
> >
> > I have searched the mailing list archives, and google, for my query,
> > but have not yet found an answer.
> >
> > Does anyone know
Anand Buddhdev <[EMAIL PROTECTED]> wrote:
>
> I'm using mysql version 3.23.58, on Fedora core 1 (the default
> supplied on the system).
>
> I have searched the mailing list archives, and google, for my query,
> but have not yet found an answer.
>
> Does anyone know if it's possible to define 2 c
On 12 Feb 2004 at 22:57, Bill Easton wrote:
> You can use + 1 instead of + interval 1 second, but it may give
> different results some day if MySQL changes the precision of
> timestamp.
Actually, that won't work in all cases. If the current timestamp is
20040213114859, then adding 1 (rather tha
Hi Craig,
> I have a very large web app that uses timestamp for unique IDs.
> Everything was rolling fine until we started getting many users per
> second, causing some of the unique IDs to not be unique -- users were
> being assigned the same timestamp. Since the web app is so large we
> don't wa
terval 1 second, but it may give
different results some day if MySQL changes the precision of timestamp.
HTH
Bill Easton
> Subject: Re: Unique IDs
> From: Craig Jackson <[EMAIL PROTECTED]>
> To: "Keith C. Ivey" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> D
ent the wheel.
Eric
> Original Message
> From: Jeff Mathis <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: "Keith C. Ivey" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Date: Thu, Feb-12-2004 11:13 AM
> Subject: Re: Unique IDs
>
> as everyone has
as everyone has pointed out, using timestamps as a unique id was a
design flaw. you should fix the problem using an auto-increment field.
that said, can you change the column type you are currently using as a
timestamp to be an auto-increment int field? the return type in both
cases is technica
On 12 Feb 2004 at 11:57, Craig Jackson wrote:
> Thanks for the speedy reply and I have already recommended
> auto_increment for the solution. We do need that quick fix until the
> problem is fixed. How would I go about making Mysql wait one second
> between inserts. We only get about 1000 hits per
, February 12, 2004 9:57 AM
To: Keith C. Ivey
Cc: [EMAIL PROTECTED]
Subject:Re: Unique IDs
On Thu, 2004-02-12 at 11:47, Keith C. Ivey wrote:
> Craig Jackson <[EMAIL PROTECTED]> wrote:
>
> > I have a very large web app that uses timestamp for unique IDs.
> >
MySQL),
sleep for a second, then try the insert again. I doubt there's a good way
to hang up the database on the issue.
Cheers;
-M
From: Craig Jackson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: "Keith C. Ivey" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subjec
On Thu, 2004-02-12 at 11:47, Keith C. Ivey wrote:
> Craig Jackson <[EMAIL PROTECTED]> wrote:
>
> > I have a very large web app that uses timestamp for unique IDs.
> > Everything was rolling fine until we started getting many users per
> > second, causing some of the unique IDs to not be unique --
1 - 100 of 156 matches
Mail list logo
