Any advice anyone ?
-- Forwarded message --
From: Neil Tompkins neil.tompk...@googlemail.com
Date: Thu, May 30, 2013 at 8:27 AM
Subject: Audit Table storage for Primary Key(s)
To: [MySQL] mysql@lists.mysql.com
Hi,
I've created a Audit table which tracks any changed fields
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 moment I've
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 keys like
1
1|2013-05-29
2|2013-05-29
2
3
1
, Carsten Pedersen cars...@bitbybit.dkwrote:
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
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
, 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
, 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
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
...@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 neil.tompk...@googlemail.com
Date: Thu, May 30, 2013 at 8:27 AM
Subject: Audit Table storage
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 rja...@yahoo-inc.com wrote:
UUID PRIMARY KEY (or even secondary index) --
Once the table gets big enough (bigger than RAM cache), each row
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 keys like
1
1
are reported on the slave.
-Hank Eskin
On Wed, Jun 15, 2011 at 4:38 PM, Hank hes...@gmail.com 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 primary key
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 auto-increment as the single primary
key And then the values being inserted
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
are reported on the slave.
-Hank Eskin
On Wed, Jun 15, 2011 at 4:38 PM, Hank hes...@gmail.com 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 primary key values
...@gmail.com 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 primary key values leaking over into a non-ignored
table with inserts immediately after the ignore
15, 2011 at 4:38 PM, Hank hes...@gmail.com 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 primary key values leaking over into a
non-ignored
table
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.
Basically, data from the ignored table
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.. but
when
this statement is replicated
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.. but
when
this statement is replicated on the slaves, instead of inserting
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 when it is
, 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) represent the last-insert-id of the replication *ignored* table
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.. but when
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.. but when
this statement is replicated
On Jun 14, 2011 3:07 AM, Hank hes...@gmail.com 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 based replication).
I'm finding an auto-increment field (part of a compound primary key)
updates
correctly
.
Claudio
On Jun 14, 2011 3:07 AM, Hank hes...@gmail.com 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 based replication).
I'm finding an auto-increment field (part of a compound primary key)
updates
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 and display
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 and display
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.
This primary key can
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 primary key could be the cust_id, bill_id
a little paranoid, but when dealing with the
Internet, I want to make my web app as secure as possible. 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
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
question is
, but when dealing with the
Internet, I want to make my web app as secure as possible. 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 Mar 10, 2011 9:23 PM, Reindl Harald h.rei...@thelounge.net 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
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 them for
fetch the record, so you have to use obfusction you can
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 used
to pull up
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
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 faqsessions
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
mysql
mysql show create table faqsessions
/2/11, Johan De Meersman vegiv...@tuxera.be wrote:
From: Johan De Meersman vegiv...@tuxera.be
Subject: Re: Two Identical Values on Primary Key Column
To: Rodrigo Ferreira rodrigof_si...@yahoo.com
Cc: mysql@lists.mysql.com
Date: Wednesday, March 2, 2011, 11:21 AM
#yiv704254679 p {margin:0
Based on my reply below, do you recommend I continue to have these indexes ?
-- Forwarded message --
From: Tompkins Neil neil.tompk...@googlemail.com
Date: Wed, Oct 13, 2010 at 8:22 PM
Subject: Re: Primary key not unique on InnoDB table
To: Travis Ard travis_...@hotmail.com
Cc
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
Subject: Fwd: Primary key
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_ci NOT NULL
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 Neil
Sorry, the word is counpound instead of composed.
--
João Cândido de Souza Neto
João Cândido de Souza Neto j...@consultorweb.cnt.br escreveu na
mensagem news:20101013144314.9787.qm...@lists.mysql.com...
I´d never seen before a composed primary key that has an auto_increment
field
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 neil.tompk...@googlemail.com
wrote:
I've the following table. But why isn't the primary key unique, e.g.
preventing
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 j...@consultorweb.cnt.br
Sorry, the word is counpound instead of composed.
--
João Cândido de Souza Neto
João Cândido de Souza Neto j...@consultorweb.cnt.br
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 neil.tompk...@googlemail.com escreveu na mensagem
news:aanlkti=xnjcaiq7bmoxg-q
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 j...@consultorweb.cnt.br
A primary key with an auto_increment is ok, but I cant think about a
primary
key with two fiels where one of them
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 (players_id,default_teams_id).
_Krishna
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,
`first_name
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 definition
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 primary
key
That's
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 primary key unique, e.g
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 primary key unique, e.g.
preventing
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 SELECT * FROM game_log
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 曹凯 tx...@hotmail.com
Hi all,
if we just know the table name but don't know the name of primary key, is
there any variables or constants
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 ?
From: theyaho
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't know what its
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 table
u can also get information of table using
use use urdbname
mysqlshow create table game_log \G
2010/2/1 曹凯 tx...@hotmail.com
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
On Mon, Jan 25, 2010 at 10:08 PM, Yong Lee yong@gogoants.com 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 able to do
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 paul.dub...@sun.com
The requirement is that it be indexed. The index need not be a primary
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 a key
Zhang yanghates...@gmail.com
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
getting
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 Worster f
2010/1/25 Yang Zhang yanghates...@gmail.com:
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.
Non
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 creating an index
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., unique key (myid
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 record (a1
Fernando,
On Wed, Oct 7, 2009 at 5:08 PM, Fer C. ferk...@gmail.com 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
update
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 will instead insert a (1,2,3) record (the a
field is the same but it still has a different b and thus it's a
different primary key, so it's not considered
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 within the same
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
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 a tradeoff
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 we'll see a lot of ordered bulk
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
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 ik...@dane-elec.co.il wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing
. 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 happier index.
kabel
--
MySQL General Mailing List
.
-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 BIGINT
2. MAC address set as primary key
Should I consider
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
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
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
--
Jim Lyons
Web developer / Database administrator
http://www.weblyons.com
, from someone with experience.
-- Pete Wilson
http://www.pwilson.net/
--- On Thu, 5/14/09, Jim Lyons jlyons4...@gmail.com wrote:
From: Jim Lyons jlyons4...@gmail.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
To: Ilia KATZ ik...@dane-elec.co.il
Cc: mysql@lists.mysql.com
Wilson
http://www.pwilson.net/
--- On Thu, 5/14/09, Jim Lyons jlyons4...@gmail.com wrote:
From: Jim Lyons jlyons4...@gmail.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
To: Ilia KATZ ik...@dane-elec.co.il
Cc: mysql@lists.mysql.com
Date: Thursday, May 14, 2009, 11
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)
-
From: Ilia KATZ [mailto:ik...@dane-elec.co.il]
Sent: Thursday, May 14, 2009 6: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 BIGINT
2. MAC address set as primary key
Should I consider
To: Ilia KATZ ik...@dane-elec.co.il
From: Fish Kungfu fish.kun...@gmail.com
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
Message-ID: f76e38f90905140653o4f6513aft103e8c3b526b3...@mail.gmail.com
--001636e90cddd7f9c70469dfa8fe
Content-Type: text/plain
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
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 more
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 really guarantee uniqueness, If you mean
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
BTW,i am using MySQL 5.0
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 unique primary key in MySQL?
Thank you
--
- michael
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
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 from
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 example. Say tables
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
[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.phone from foo,bar where foo.phone=bar.phone
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 is efficient:
mysql explain select bar.phone from foo,bar where
foo.phone=bar.phone
1 - 100 of 569 matches
Mail list logo
