Ah-ha, excuse my earlier response, I was under the impression you were
trying to track schema changes etc.
A
On Fri, May 31, 2013 at 7:54 PM, Rick James wrote:
> UUID PRIMARY KEY (or even secondary index) --
> Once the table gets big enough (bigger than RAM cache), each row INSERTed
Original Message-
From: Neil Tompkins [mailto:neil.tompk...@googlemail.com]
Sent: Friday, May 31, 2013 3:43 AM
To: [MySQL]
Subject: Fwd: Audit Table storage for Primary Key(s)
Any advice anyone ?
-- Forwarded message --
From: Neil Tompkins
Date: Thu, May 30, 2013 at 8:27 AM
UUID PRIMARY KEY (or even secondary index) --
Once the table gets big enough (bigger than RAM cache), each row INSERTed (or
SELECTed) will be a disk hit. (Rule of Thumb: only 100 hits/sec.) This is
because _random_ keys (like UUID) make caching useless. Actually, the slowdown
will be
sten
>
>
> On 31-05-2013 12:58, Neil Tompkins wrote:
>
>> The kind of look ups will be trying to diagnose when and by who applied
>> a update. So the primary key of the audit is important. My question is
>> for performance, should the primary key be stored as a indexed fiel
, Neil Tompkins wrote:
The kind of look ups will be trying to diagnose when and by who applied
a update. So the primary key of the audit is important. My question is
for performance, should the primary key be stored as a indexed field
like I mentioned before, or should I have a actual individual field
The kind of look ups will be trying to diagnose when and by who applied a
update. So the primary key of the audit is important. My question is for
performance, should the primary key be stored as a indexed field like I
mentioned before, or should I have a actual individual field per primary key
e applying.
On Fri, May 31, 2013 at 9:58 AM, Carsten Pedersen wrote:
On 30-05-2013 09:27, Neil Tompkins wrote:
Hi,
I've created a Audit table which tracks any changed fields for multiple
tables. In my Audit table I'm using a UUID for the primary key. However
I
need to have a referen
created a Audit table which tracks any changed fields for multiple
>> tables. In my Audit table I'm using a UUID for the primary key. However
>> I
>> need to have a reference back to the primary key(s) of the table audited.
>>
>> At the moment I've a VARCH
On 30-05-2013 09:27, Neil Tompkins wrote:
Hi,
I've created a Audit table which tracks any changed fields for multiple
tables. In my Audit table I'm using a UUID for the primary key. However I
need to have a reference back to the primary key(s) of the table audited.
At the mom
Any advice anyone ?
-- Forwarded message --
From: Neil Tompkins
Date: Thu, May 30, 2013 at 8:27 AM
Subject: Audit Table storage for Primary Key(s)
To: "[MySQL]"
Hi,
I've created a Audit table which tracks any changed fields for multiple
tables. In my Audit ta
Hi,
I've created a Audit table which tracks any changed fields for multiple
tables. In my Audit table I'm using a UUID for the primary key. However I
need to have a reference back to the primary key(s) of the table audited.
At the moment I've a VARCHAR field which stores primary
removed and mysql restarted so "db.log" is no longer ignored in
>> >> replication,
>> >> this bug goes away and correct results are reported on the slave.
>> >>
>> >> -Hank Eskin
>> >>
>> >>
>> >> On Wed, J
s no longer ignored in
> >> replication,
> >> this bug goes away and correct results are reported on the slave.
> >>
> >> -Hank Eskin
> >>
> >>
> >> On Wed, Jun 15, 2011 at 4:38 PM, Hank wrote:
> >>
> >> >
> >
ger ignored in
>> replication,
>> this bug goes away and correct results are reported on the slave.
>>
>> -Hank Eskin
>>
>>
>> On Wed, Jun 15, 2011 at 4:38 PM, Hank wrote:
>>
>> >
>> > This is a follow-up to my previous post. I have been nar
t;
> -Hank Eskin
>
>
> On Wed, Jun 15, 2011 at 4:38 PM, Hank wrote:
>
> >
> > This is a follow-up to my previous post. I have been narrowing down what
> > is causing this bug. It is a timing issue of a replication ignored table
> > with an auto-increment pri
this bug goes away and correct results are reported on the slave.
-Hank Eskin
On Wed, Jun 15, 2011 at 4:38 PM, Hank wrote:
>
> This is a follow-up to my previous post. I have been narrowing down what
> is causing this bug. It is a timing issue of a replication ignored table
> with an
This is a follow-up to my previous post. I have been narrowing down what is
causing this bug. It is a timing issue of a replication ignored table with
an auto-increment primary key values leaking over into a non-ignored table
with inserts immediately after the ignore table has had rows inserted
more
> information as to what's causing it. I plan to write it up tomorrow and
> post it.
>
> Basically, everything works perfectly, until I add a
> "replication-ignore-table=xxx" statement in my.cnf where "xxx" is a
> different table with a unique id INT
hing works perfectly, until I add a
"replication-ignore-table=xxx" statement in my.cnf where "xxx" is a
different table with a unique id INT auto-increment as the single primary
key And then the values being inserted into the "test" table (above, not
ignored) repres
2011/06/13 22:38 -0400, Hank
But that bug report was closed two years ago. I have no idea if it's the
server sending bad data or the slaves. I think it's the slaves, because on
the slave error, it clearly is getting this statement: "insert into test
values (1,null)" to replicate, but wh
gt; >> On Mon, Jun 13, 2011 at 10:33 PM, Claudio Nanni <
> claudio.na...@gmail.com>wrote:
> >>
> >>> Hank,
> >>>
> >>> I can't reproduce it right now,
> >>> But it really seems a bug.
> >>> Just a shot in the d
>>
>>
>> On Mon, Jun 13, 2011 at 10:33 PM, Claudio Nanni wrote:
>>
>>> Hank,
>>>
>>> I can't reproduce it right now,
>>> But it really seems a bug.
>>> Just a shot in the dark, Are you sure you have statement based
hot in the dark, Are you sure you have statement based and not
>> mixed replication?
>> I don't even know if that would affect , just an idea.
>>
>> Claudio
>> On Jun 14, 2011 3:07 AM, "Hank" wrote:
>> > Hello All,
>> >
>> >
n't even know if that would affect , just an idea.
>
> Claudio
> On Jun 14, 2011 3:07 AM, "Hank" wrote:
> > Hello All,
> >
> > I have a 64bit, 5.5.8 master, and this bug appears on both 5.5.11 and
> 5.5.8
> > 32 and 64-bit slaves (statement bas
All,
>
> I have a 64bit, 5.5.8 master, and this bug appears on both 5.5.11 and
5.5.8
> 32 and 64-bit slaves (statement based replication).
>
> I'm finding an auto-increment field (part of a compound primary key)
updates
> correctly using "null" to insert the next value on
Hello All,
I have a 64bit, 5.5.8 master, and this bug appears on both 5.5.11 and 5.5.8
32 and 64-bit slaves (statement based replication).
I'm finding an auto-increment field (part of a compound primary key) updates
correctly using "null" to insert the next value on the master.
Hi.
On Thursday 10 Mar 2011 at 20:09 mos wrote:
[snip]
> Let's say I have a Document_Id column and the url is
> www.mydocuments.com/public?docid=4
> to retrieve document_id=4, I don't want someone to write a program to
> retrieve all of my public documents and download them. I want them to go
>
espect.
I am building a web application that uses MySQL 5.5 with Innodb tables
and I don't want the user to see the actual primary key value on the web
page. The primary key could be the cust_id, bill_id etc and is usually
auto increment. This primary key can appear in the url and will be us
column with a checksum deriving from the Id?
what exactly do you not understand?
fecth the record by its primary key is pretty fast
decide the data-output by a checksum which is independent
to the key
how will you do this any other way?
you can not use hash functions because you can not revert
On Mar 10, 2011 9:23 PM, "Reindl Harald" wrote:
>
>
>
> Am 10.03.2011 21:09, schrieb mos:
> > At 12:37 PM 3/10/2011, Claudio Nanni wrote:
> >
> >> Hi there,
> >> Yes I think its actually a pattern a few hundreds million sites solved
already :)
> >
> > Great. How did they do it? :)
> >
> >> And any
sible. I'm hoping
some
>> > of you can offer me some ideas in this respect.
>> >
>> > I am building a web application that uses MySQL 5.5 with Innodb tables
and
>> > I don't want the user to see the actual primary key value on the web
page.
>> >
Am 10.03.2011 21:09, schrieb mos:
> At 12:37 PM 3/10/2011, Claudio Nanni wrote:
>
>> Hi there,
>> Yes I think its actually a pattern a few hundreds million sites solved
>> already :)
>
> Great. How did they do it? :)
>
>> And any way to encrypt (scramble)the http get string would do. But my
uses MySQL 5.5 with Innodb tables and
> I don't want the user to see the actual primary key value on the web page.
> The primary key could be the cust_id, bill_id etc and is usually auto
> increment. This primary key can appear in the url and will be used to pull
> up a record and dis
On Thursday 10 March 2011 11:45:27 am Reindl Harald wrote:
> Am 10.03.2011 18:10, schrieb mos:
> > I am building a web application that uses MySQL 5.5 with Innodb tables
> > and I don't want the user to see the actual primary key value on the web
> > page. The primar
Am 10.03.2011 18:10, schrieb mos:
> I am building a web application that uses MySQL 5.5 with Innodb tables and I
> don't want the user to see the actual
> primary key value on the web page. The primary key could be the cust_id,
> bill_id etc and is usually auto increment.
&
;
> I am building a web application that uses MySQL 5.5 with Innodb tables and
> I don't want the user to see the actual primary key value on the web page.
> The primary key could be the cust_id, bill_id etc and is usually auto
> increment. This primary key can appear in the url and w
ding a web application that uses MySQL 5.5 with Innodb tables and
I don't want the user to see the actual primary key value on the web page.
The primary key could be the cust_id, bill_id etc and is usually auto
increment. This primary key can appear in the url and will be used to pull
up a record an
--+
1 row in set (0.00 sec)
mysql>
--- On Wed, 3/2/11, Johan De Meersman wrote:
From: Johan De Meersman
Subject: Re: Two Identical Values on Primary Key Column
To: "Rodrigo Ferreira"
Cc: mysql@lists.mysql.com
Date: Wednesday, March 2, 2011, 11:21 AM
#yiv704254679 p {margin:0;}
wo Identical Values on Primary Key Column
> Hi all,
> I have just experienced a strange problem with mysql production
> database. The table faqsessions have a primary key on column `Code`
> and the above select return 2 rows!
> mysql>
> my
Hi all,
I have just experienced a strange problem with mysql production database. The
table faqsessions have a primary key on column `Code` and the above select
return 2 rows!
mysql>
mysql>
mysql> show create table fa
join, indexing that column may not be a benefit. Running
EXPLAIN will tell you whether or not the index you anticipate is actually
being used for your query.
-Travis
From: Tompkins Neil [mailto:neil.tompk...@googlemail.com]
Sent: Friday, October 15, 2010 3:43 AM
To: [MySQL]; Travis Ard
Subje
Based on my reply below, do you recommend I continue to have these indexes ?
-- Forwarded message --
From: Tompkins Neil
Date: Wed, Oct 13, 2010 at 8:22 PM
Subject: Re: Primary key not unique on InnoDB table
To: Travis Ard
Cc: "[MySQL]"
Hi Travis,
Thanks for you
requirements.
>
> -Travis
>
> -Original Message-
> From: Tompkins Neil [mailto:neil.tompk...@googlemail.com]
> Sent: Wednesday, October 13, 2010 8:37 AM
> To: [MySQL]
> Subject: Primary key not unique on InnoDB table
>
> I've the following table. But why i
and add to
your storage requirements.
-Travis
-Original Message-
From: Tompkins Neil [mailto:neil.tompk...@googlemail.com]
Sent: Wednesday, October 13, 2010 8:37 AM
To: [MySQL]
Subject: Primary key not unique on InnoDB table
I've the following table. But why isn't the pri
Shawn it is fine. I thought my primary key was just 1 field.
On Wed, Oct 13, 2010 at 4:44 PM, Shawn Green (MySQL) <
shawn.l.gr...@oracle.com> wrote:
> On 10/13/2010 11:37 AM, Tompkins Neil wrote:
>
>> Shawn, sorry my error, I didn't realise I had two fields as the primar
On 10/13/2010 11:37 AM, Tompkins Neil wrote:
Shawn, sorry my error, I didn't realise I had two fields as the primary key
That's misinformation. You can have multiple fields as a primary key.
Show us what you think is duplicate data and I may be able to help you
fix your
On 10/13/2010 10:37 AM, Tompkins Neil wrote:
I've the following table. But why isn't the primary key unique, e.g.
preventing duplicates if entered ?
CREATE TABLE `players_master` (
`players_id` bigint(20) NOT NULL AUTO_INCREMENT,
`default_teams_id` bigint(20) NOT NULL,
`
Of course, sorry totally stupid should I recognised that.
Thanks
Neil
On Wed, Oct 13, 2010 at 3:46 PM, Krishna Chandra Prajapati <
prajapat...@gmail.com> wrote:
> Hi Neil,
>
> Yes, primary key is always unique.
>
> In your case, you are using composite key (player
I see what you mean. Infact this is wrong and I will be dropping the second
field in the primary key.
2010/10/13 João Cândido de Souza Neto
> A primary key with an auto_increment is ok, but I cant think about a
> primary
> key with two fiels where one of them is autoincrem
A primary key with an auto_increment is ok, but I cant think about a primary
key with two fiels where one of them is autoincrement. Am I completely
wrong?
--
João Cândido de Souza Neto
"Tompkins Neil" escreveu na mensagem
news:aanlkti=xnjcaiq7bmoxg-q+4nowdhv8uaj9dcqrol...@mail
Sorry Joao, I thought that was pretty standard to have a primary key with
auto_increment ??
2010/10/13 João Cândido de Souza Neto
> Sorry, the word is counpound instead of composed.
>
> --
> João Cândido de Souza Neto
>
> ""João Cândido de Souza Neto&qu
Hi Neil,
Yes, primary key is always unique.
In your case, you are using composite key (players_id,default_teams_id).
_Krishna
On Wed, Oct 13, 2010 at 8:07 PM, Tompkins Neil wrote:
> I've the following table. But why isn't the primary key unique, e.g.
> preventing dupli
Sorry, the word is counpound instead of composed.
--
João Cândido de Souza Neto
""João Cândido de Souza Neto"" escreveu na
mensagem news:20101013144314.9787.qm...@lists.mysql.com...
> I´d never seen before a composed primary key that has an auto_increment
> fie
I´d never seen before a composed primary key that has an auto_increment
field on it.
May be I can be wrong but I think it wont work properly.
As far as I know, if you have an auto_increment field it must be your single
primary key. Am I wrong?
--
João Cândido de Souza Neto
"Tompkins
I've the following table. But why isn't the primary key unique, e.g.
preventing duplicates if entered ?
CREATE TABLE `players_master` (
`players_id` bigint(20) NOT NULL AUTO_INCREMENT,
`default_teams_id` bigint(20) NOT NULL,
`first_name` varchar(100) COLLATE utf8_unicode_c
u can also get information of table using
use> use urdbname
mysql>show create table game_log \G
2010/2/1 曹凯
>
> hi Jesper,
>
>
> thanks a lot! That's what I want. thank u againCC: mysql@lists.mysql.com
> From: jes...@noggin.com.au
> Subject: Re: how to get
hi Jesper,
thanks a lot! That's what I want. thank u againCC: mysql@lists.mysql.com
From: jes...@noggin.com.au
Subject: Re: how to get the name of primary key ?
Date: Mon, 1 Feb 2010 20:26:36 +1100
To: tx...@hotmail.com
On 01/02/2010, at 7:33 PM, 曹凯 wrote:
Hi all,
if we just know the
On 01/02/2010, at 7:33 PM, 曹凯 wrote:
Hi all,
if we just know the table name but don't know the name of primary
key, is there any variables or constants could instead of the PK?
for example:
there is a table "game_log", and now I have the last inserted_id
but don&
Hi Thiyaghu,
I have already got the last_insert_id. now I wanna know if there are any
variables or constants to instead of game_log's primary key cos I don't know
its name.
> Date: Mon, 1 Feb 2010 14:24:59 +0530
> Subject: Re: how to get the name of primary key ?
Hi,
Use
*SELECT * FROM game_log WHERE this_table's_PK = last_insert_id()*
It will help you.
Regards,
Thiyaghu CK,
MySQL DBA
www.mafiree.com
2010/2/1 曹凯
>
> Hi all,
>
> if we just know the table name but don't know the name of primary key, is
> there any variables o
Hi all,
if we just know the table name but don't know the name of primary key, is there
any variables or constants could instead of the PK?
for example:
there is a table "game_log", and now I have the last inserted_id but don't know
what its primary_id is,
how can I &qu
Yeah, Paul...
This is so clear...the auto_increment column may be indexed like:
- KEY();
- UNIQUE();
- PRIMARY KEY()
...when you create or alter a table.
--
Wagner Bianchi
2010/1/25 Paul DuBois
The requirement is that it be indexed. The index need not be a primary key.
>
>
On Mon, Jan 25, 2010 at 10:08 PM, Yong Lee wrote:
> yah, mysql only allows one auto increment field n that's used as the
> primary key in tables. I don't think it has to be the primary key as
> long as it is a unique key i think that's okay.
>
> so u should be a
yah, mysql only allows one auto increment field n that's used as the
primary key in tables. I don't think it has to be the primary key as
long as it is a unique key i think that's okay.
so u should be able to do : create table (myid int unsigned not null
auto_increment., u
The requirement is that it be indexed. The index need not be a primary key.
mysql> create table t (i int not null auto_increment, index(i)) engine innodb;
Query OK, 0 rows affected (0.45 sec)
On Jan 25, 2010, at 9:39 AM, Yang Zhang wrote:
> Right, I saw the docs. I'm fine with
2010/1/25 Yang Zhang :
> Right, I saw the docs. I'm fine with creating an index on it, but the
> only way I've successfully created a table with auto_increment is by
> making it a primary key. And I still don't understand why this
> requirement is there in the first pl
Right, I saw the docs. I'm fine with creating an index on it, but the
only way I've successfully created a table with auto_increment is by
making it a primary key. And I still don't understand why this
requirement is there in the first place.
On Mon, Jan 25, 2010 at 10:32 AM, Tom
al Message-
From: "Yang Zhang"
Sent: Monday, January 25, 2010 10:21am
To: mysql@lists.mysql.com
Subject: auto_increment without primary key in innodb?
In innodb, is it possible to have an auto_increment field without
making it a (part of a) primary key? Why is this a requirement? I'm
In innodb, is it possible to have an auto_increment field without
making it a (part of a) primary key? Why is this a requirement? I'm
getting the following error. Thanks in advance.
ERROR 1075 (42000): Incorrect table definition; there can be only one
auto column and it must be defined as
gt; INSERT INTO table (a,b,c) VALUES (1,2,3)
> ON DUPLICATE KEY UPDATE b=2,c=3;
That has the same effect as REPLACE for me.
The primary key is "a,b" so, it's possible that there's a (1,4,5)
record already in the table that I want updated but INSERT ON
DUPLICATE KEY UPDATE
Fernando,
On Wed, Oct 7, 2009 at 5:08 PM, Fer C. wrote:
> Hello
> I have a table with a compound primary key (a1,a2) and I want to
> insert a record (b1,b2) in th cases where there's no a1 value matching
> b1, and if there's already a b1 value in the form (b1,c2) then just
Hello
I have a table with a compound primary key (a1,a2) and I want to
insert a record (b1,b2) in th cases where there's no a1 value matching
b1, and if there's already a b1 value in the form (b1,c2) then just
update it so that it turns into (b1,b2).
So, If I want to insert-update the r
Michael,
We're counting on batch inserts of constant 2 leftmost columns of the
primary key.
We would be selecting within constant values for the leftmost columns as well.
For example, our primary key is
country_id, city_id, auto_inc, ...
We'll always be looking for data from withi
and had to
> sacrifice on the length of the primary key.
> And we got fairly good results from query profiling using maatkit.
> One thing that shocked me was the overhead of random inserts primary
> key updates.
> It's definitely a tradeoff.
> We're reasonably certain that
Michael,
Yeah. We're trying to maximize the benefits of clustering and had to
sacrifice on the length of the primary key.
And we got fairly good results from query profiling using maatkit.
One thing that shocked me was the overhead of random inserts primary
key updates.
It's definitely
We have a multi-column primary key with an auto-increment column as
the 3rd column in the primary key in InnoDB.
Is there a requirement to have the auto-increment column as the
leftmost column in the primary key in order for InnoDB to cluster by
the multi-column primary key?
I don't believe
"I've run up on the rock of a binary (meaning: indecipherable) field."
SELECT hex(some_binary_field) FROM table;
Solved.
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of
y 2009 09:53:58 -0400
To: Ilia KATZ
From: Fish Kungfu
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
Message-ID:
--001636e90cddd7f9c70469dfa8fe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Since MAC addreses als
e an IP like 192.168.0.0 now. Validate it.
if ( false !== ip2long( $temp ) )
{
$result = $temp."/".$cidr_bits;
}
}
return $result;
}
/**
* Returns true if the string is a valid CIDR.
*
* @access public
* @param
I agree, and didn't mean to say that I disagreed. This is certainly one of the
top five principles to follow, imo. Too many times, while trouble-shooting,
I've run up on the rock of a binary (meaning: indecipherable) field.
What is the cost of including the binary representation (for indexing)
er.
>
> I'll be interested in the answer, though, from someone with experience.
>
> -- Pete Wilson
> http://www.pwilson.net/
>
>
> --- On Thu, 5/14/09, Jim Lyons wrote:
>
> > From: Jim Lyons
> > Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
>
be interested in the answer, though, from someone with experience.
-- Pete Wilson
http://www.pwilson.net/
--- On Thu, 5/14/09, Jim Lyons wrote:
> From: Jim Lyons
> Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
> To: "Ilia KATZ"
> Cc: mysql@lists.mysql.
e:
> 1. MAC address defined as BIGINT
> 2. MAC address set as primary key
>
> Should I consider changing it to CHAR(12)?
>
> Replies will be appreciated.
> Ilia
>
>
>
>
--
Jim Lyons
Web developer / Database administrator
http://www.weblyons.com
On Thu, 14 May 2009, Ilia KATZ wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi
It depends. You may convert the MAC address to a decimal integer and store
6th byte
the last 2 bytes (of the BIGINT) left unused.
Ilia
From: Fish Kungfu [mailto:fish.kun...@gmail.com]
Sent: Thursday, May 14, 2009 3:54 PM
To: Ilia KATZ
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12
a problem.
>-Original Message-
>From: Ilia KATZ [mailto:ik...@dane-elec.co.il]
>Sent: Thursday, May 14, 2009 9:26 AM
>To: mysql@lists.mysql.com
>Subject: MAC address as primary key - BIGINT or CHAR(12)
>
>Hi.
>Currently I have a table:
>1. MAC address defined as BIGI
ress defined as BIGINT
> 2. MAC address set as primary key
>
> Should I consider changing it to CHAR(12)?
>
> Replies will be appreciated.
> Ilia
And, if you use default charsets of anything else, make sure you set this
column to CHARACTER SET ascii. A smaller index is a happi
Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
would say go with CHAR(12).
On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changin
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
>> I wish my id has the same length,auto_increment can do this?
>>
>
> I have a idear to generate unique primary key:
>
> select concat(cast(unix_timestamp() as char) , cast(substr(rand(),3,4) as
> char(4)));
>
> Is this ok? any good idear?
Your routine does not
If you just don't want a primary key in your major data tables, then create
a table for the express purpose of generating primary keys that uses
auto_increment. Something like:
create table myseq (x serial;)
Each time you need a new key, get the next value from that table. It would
be
(
> id VARCHAR(20) NOT NULL,
> product_id INT NOT NULL,
> product_quantity INT NOT NULL,
> ...
> ...
> user_id INT NOT NULL,
> current_timestamp TIMESTAMP,
> primary key (id)
> );
>
> I will not use auto_increment
>
> Is there other way to generate unique pr
BTW,i am using MySQL 5.0
I have a shopping cart table like this:
CREATE TABLE shopping_cart(
id VARCHAR(20) NOT NULL,
product_id INT NOT NULL,
product_quantity INT NOT NULL,
...
...
user_id INT NOT NULL,
current_timestamp TIMESTAMP,
primary key (id)
);
I will not use auto_increment
Is there other way to generate
Hello Steve,
> Ok, I'm a little new a this, so be gentle!! :)
>
> I was looking into the InnoDB engine for some tables I have, and would
like
> to use the PK/FK on some of the data.
>
> It appears that the PK/FK is mainly used for updating/deleting data,
> correct? I can't use it to retreive data
Ok, I'm a little new a this, so be gentle!! :)
I was looking into the InnoDB engine for some tables I have, and would like
to use the PK/FK on some of the data.
It appears that the PK/FK is mainly used for updating/deleting data,
correct? I can't use it to retreive data from multiple tables
Hi Patrick, all !
Patrick J. McEvoy wrote:
I have two MyISAM tables; each uses 'phone' as a primary key. Finding
rows where the primary keys match is efficient:
mysql> explain select bar.phone from foo,bar where foo.phone=bar.phone;
[[...]}
Ok, let us take some simple exampl
> I would have thought your not = though is matching a lot more rows every
> time..
The field is UNIQUE PRIMARY KEY in both tables, so there
should be 0 or 1 matches.
> I would look into using where not exists as a subselect
My MySQL book (O'Reilly second edition) does not ment
one =
> bar.phone);
>
> something like that.
>
> On Tue, Apr 15, 2008 at 5:00 PM, Patrick J. McEvoy <[EMAIL PROTECTED]>
> wrote:
>
> > I have two MyISAM tables; each uses 'phone' as a primary key. Finding
rows
> > where the primary keys match
J. McEvoy <[EMAIL PROTECTED]>
wrote:
> I have two MyISAM tables; each uses 'phone' as a primary key. Finding rows
> where the primary keys match is efficient:
>
> mysql> explain select bar.pho
1 - 100 of 588 matches
Mail list logo
