; > -Original Message-
> > From: Rick James
> > Sent: Wednesday, January 30, 2013 1:08 PM
> > To: 'Jeremy Chase'; mysql@lists.mysql.com
> > Subject: RE: InnoDB interaction between secondary and primary keys.
> >
> > secondarykey and r
ql@lists.mysql.com
> Subject: RE: InnoDB interaction between secondary and primary keys.
>
> secondarykey and redundantkey are redundant with each other -- in all
> versions of InnoDB.
>
> One "expert" said that redundant key would have two copies of `1`,`2`.
> I think h
.com
> Subject: InnoDB interaction between secondary and primary keys.
>
> Hello,
>
> I've been working with a secondary index and would like some
> clarification about how the primary columns are included. So, in the
> following example, is the secondaryKey effective
This isn't true for innodb.
I think the only requirement is that you need to have a unique index
on the auto increment column.
We created a composite primary key + auto_increment to take advantage
of clustering by primary key while satisfying unique constraint for
the primary key. It worked out wel
y projects I am working on, where I've done this, but done it in
code, rather than in mysql.
Steven Staples
> -Original Message-
> From: Dušan Pavlica [mailto:pavl...@unidataz.cz]
> Sent: June 29, 2010 11:26 AM
> To: Victor Subervi
> Cc: mysql@lists.mysql.com
>
You were talking about multiple fields in the primary key, not multiple
primary keys.
On 06/29/2010 03:51 PM, Johan De Meersman wrote:
Correct, but you still can't have more than one primary key. Kind of
defeats the idea of it being primary, really.
On Tue, Jun 29, 2010 at 3:36 PM,
to_increment primary key, you cant have
any other field in its primary key.
Makes sense. Actually, I was just copying what someone else gave me and
adding the auto_increment, then I got to wondering, what is the purpose of
having two primary keys?
TIA,
V
--
MySQL General Mailing List
F
2010/6/29 João Cândido de Souza Neto
> I think the best, or may be the right way is to use picture_id as primary
> key and a unique index to product_sku.
>
Yes, sounds good. So the purpose, then, is to speed lookups on fields
commonly accessed. I'd forgotten that.
Thanks,
V
I think the best, or may be the right way is to use picture_id as primary
key and a unique index to product_sku.
--
João Cândido de Souza Neto
"Victor Subervi" escreveu na mensagem
news:aanlktikzksmbx5hue0x_q3hx_68gicndghpkjdrna...@mail.gmail.com...
> Hi;
> I have the following:
>
> create
On 6/29/2010 9:24 AM, Victor Subervi wrote:
Hi;
I have the following:
create table pics (
picture_id int auto_increment primary key,
product_sku int not null primary key,
picture_num int not null,
picture_desc varchar(100),
picture_data longblob
);
which doesn't work I need to au
If you use innodb, primary key lookups are far faster than secondary
indexes.
Peter
On 06/29/2010 03:34 PM, João Cândido de Souza Neto wrote:
I think the real question is: What´s the purpose of any other field in my
primary key if the first one is an auto_increment and will never repeat?
t is the purpose of
having two primary keys?
TIA,
V
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
at is the purpose of
having two primary keys?
TIA,
V
As far as I know, if you have an auto_increment primary key, you cant have
any other field in its primary key.
João Cândido.
"Victor Subervi" escreveu na mensagem
news:aanlktikzksmbx5hue0x_q3hx_68gicndghpkjdrna...@mail.gmail.com...
> Hi;
> I have the following:
>
> create table pics (
> p
Hi;
I have the following:
create table pics (
picture_id int auto_increment primary key,
product_sku int not null primary key,
picture_num int not null,
picture_desc varchar(100),
picture_data longblob
);
which doesn't work I need to auto_increment and declare primary key on two
fi
right...
- Original Message -
From: "Gabriel PREDA" <[EMAIL PROTECTED]>
To: "Ferindo Middleton" <[EMAIL PROTECTED]>
Cc: "Dan Buettner" <[EMAIL PROTECTED]>;
Sent: Friday, October 06, 2006 6:31 PM
Subject: Re: multiple primary keys on one
You will have to UPDATE to NULL those fields, modify the aplication to
enter NULL instead of empty-string... Then add the UNIQUE INDEX...
In MySQL (unless modified) the dafault is that NULL values are
incomparable thus allowing the creation of a UNIQUE INDEX.
-- -- -- -- -- -- -- -- -- -- -- --
d identifier.
>
> However, I want to keep this same restriction while also ensuring that no
> two records have the same email_address and schedule_id identifier...
>
> You can't have the db enforce two different primary keys on one table, so
> how would I implement having
name and schedule_id identifier.
>
> However, I want to keep this same restriction while also ensuring that
no
> two records have the same email_address and schedule_id identifier...
>
> You can't have the db enforce two different primary keys on one table,
so
> how would I i
exact same name and schedule_id identifier.
However, I want to keep this same restriction while also ensuring that no
two records have the same email_address and schedule_id identifier...
You can't have the db enforce two different primary keys on one table, so
how would I implement having
s have the same email_address and schedule_id identifier...
You can't have the db enforce two different primary keys on one table, so
how would I implement having this kind of restriction, which, in itself,
seems to require that I have a second primary key to enforce another
constraint to dissa
.
However, I want to keep this same restriction while also ensuring that no
two records have the same email_address and schedule_id identifier...
You can't have the db enforce two different primary keys on one table, so
how would I implement having this kind of restriction, which, in itself,
see
Derek, I was able to replicate all the behaviors you describe in 5.0.21.
I noticed you have a signed INT in one table and an UNsigned INT in
the other. I changed t1 to UNsigned and then the query returns the
results you would expect:
+---+
| course_id |
+---+
|-2 |
|
Can someone tell me what's wrong with this test:
create table t1 ( course_id int(10) signed not null, primary key
(course_id) );
create table t2 ( course_id int(10) unsigned not null, primary key
(course_id) );
insert into t1 values
(1),(-1),(-2),(2),(3),(4),(5),(6),(7),(8),(65),(66),(67),(68
AIL PROTECTED]>
To: "'Kishore Jalleda'" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, April 27, 2006 9:11 AM
Subject: RE: Multiple primary keys
Thanks all. The query I run is a subquery.
I noticed joined query run a lot faster than the sub.
This is the sub
218 classC: 357
So not having a primary key/index will slow my queries?
-Original Message-
From: Kishore Jalleda [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 27, 2006 10:49 AM
To: nngau
Cc: mysql@lists.mysql.com
Subject: Re: Multiple primary keys
On 4/27/06, nngau <[EMAIL PROT
On 4/27/06, nngau <[EMAIL PROTECTED]> wrote:
>
> Can someone figure out what's going on. This is the only change
> I made to this table. Basically I don't want any duplicate rows, so
> I setup 4 fields to be my primary key.
>
> When I do a simple select query it takes nearly 30 seconds to complete.
Quoting nngau <[EMAIL PROTECTED]>:
Can someone figure out what's going on. This is the only change
I made to this table. Basically I don't want any duplicate rows, so
I setup 4 fields to be my primary key.
If you don't want any duplicate rows, use UNIQUE, all those primar
Can someone figure out what's going on. This is the only change
I made to this table. Basically I don't want any duplicate rows, so
I setup 4 fields to be my primary key.
When I do a simple select query it takes nearly 30 seconds to complete.
This is affecting my websites and taking a very long t
@lists.mysql.com
Subject: Re: Table with multiple primary keys - How
It is not possible to have more than one PRIMARY
key per table.
Maybe you need to use one PRIMARY key as the main index into
the table, then use UNIQUE or KEY which is a synonym for
INDEX on the other two columns.
This book will
It is not possible to have more than one PRIMARY
key per table.
Maybe you need to use one PRIMARY key as the main index into
the table, then use UNIQUE or KEY which is a synonym for
INDEX on the other two columns.
This book will help you ALOT with designing tables.
It will also teach you how
- Original Message -
From: "fbsd_user" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, March 07, 2006 11:40 PM
Subject: Table with multiple primary keys - How
What I am trying to do here is have 3 separate primary keys.
Creating a mysql select on either of the Logon_id
In the last episode (Mar 07), fbsd_user said:
> What I am trying to do here is have 3 separate primary keys. Creating
> a mysql select on either of the Logon_id, email_addr, or last_name
> fields will do a single read to the matching value. Like having 3
> different indexes into th
What I am trying to do here is have 3 separate primary keys.
Creating a mysql select on either of the Logon_id, email_addr,
or last_name fields will do a single read to the matching value.
Like having 3 different indexes into the same table.
I don't want those 3 field concatenated togeth
- Original Message -
From: "James Harvard" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, December 21, 2005 9:08 PM
Subject: Re: Are primary keys essential?
Thanks the on & off-list replies, but I obviously didn't explain my
situation very well!
My app is ess
>
> Shawn, I'm not quite clear what you are saying in your second last
> paragraph. When you have this situation:
>
> ID (autogenerated) PART_NOPART_DESCRIPTION
> 1 A01 Widget
> 2 B03Grapple Grommet
> 3
Hi James,
If the tables you use have primary keys that _YOU_ don't need or use then,
for you, they are not essential.
I do have a question, though. You are working with SQL tables, aren't you?
And from wherever they came from or exist, I presume from your reply that
you don'
bject: Re: Are primary keys essential?
In hindsight my thread title was misleading - sorry. Should have been
"are primary keys _always_ essential?".
JH
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTEC
In hindsight my thread title was misleading - sorry. Should have been "are
primary keys _always_ essential?".
JH
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Thanks the on & off-list replies, but I obviously didn't explain my situation
very well!
My app is essentially creating summary reports from large amounts of data. It
is _not_ doing the actual data warehousing. It's international trade data.
The data tables contain foreign keys for stuff like d
ow up as something.
Bottom line, uniqueness, stability and order are the "sine qua non"* of good
data organization. (*Means without which nothing.)
HTH,
Ken
- Original Message -
From: "James Harvard" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, December
The PK thread has reminded me of a question I had but never resolved when
designing the table structure of the big data warehouse app I was droning on
about just now in the aforementioned thread. As need to import some hundreds of
millions of rows in the next week, I think now would be a good id
Auto-incremented integers (be it bigint, mediumint, etc) are, from a
purist point of view, better than "natural" primary keys, like part
number etc. Read Practical Issues in Database Management, by Fabian
Pascal. He argues against natural primary keys, because the business
rules th
I admit I too am in the habit of always defining an auto_increment primary key,
but recently gathered my courage and omitted it from a match-up table joining a
table of users to a table of categories they were allowed to use - an
auto-generated primary key would have been completely redundant. I
about how to
use the ID? Or what's it for?
Ken
- Original Message -
From: "Rhino" <[EMAIL PROTECTED]>
To: "Kenneth Wagner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "mysql"
Sent: Wednesday, December 21, 2005 4:57 PM
Subject:
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Kenneth Wagner" <[EMAIL PROTECTED]>
Cc: "mysql" ; "Rhino" <[EMAIL PROTECTED]>
Sent: Wednesday, December 21, 2005 5:15 PM
Subject: Re: Reason for Auto-increment primary keys?
"Ke
o post a copy of the INT column
"parent_id".
In my mind it's always good to use UNIQUE in these cases so your real
primary keys are in your table structure to prevent getting bad data.
My $0.02
Josh
--
MySQL General Mailing List
For list archives: http://lists.mysq
n
> added or updated
> by PK, timestamp, activity type and updatedbyuserID.
>
> So, there's 2 cents worth.
>
> Wondering how relevant this is?
>
> HTH,
>
> Ken Wagner
>
>
>
> - Original Message -
> From: "Rhino" <[EMAIL PROTECTED]&
If this trend is real, it doesn't seem like a very good trend to me. For
example, if you were keeping track of parts in a warehouse, why would anyone
make a table that looked like this:
ID (autogenerated PK) PART_NOPART_DESCRIPTION
1 A01
is people putting
auto-incremented integer primary keys on their tables.
Maybe I'm just "old school" but I've always thought that you should
choose a primary key based on data that is actually in the table
whenever possible, rather than generating a new value out of thin a
added or updated
by PK, timestamp, activity type and updatedbyuserID.
So, there's 2 cents worth.
Wondering how relevant this is?
HTH,
Ken Wagner
- Original Message -
From: "Rhino" <[EMAIL PROTECTED]>
To: "mysql"
Sent: Wednesday, December 21, 2005 2:54 P
One technique that I see a lot on this mailing list is people putting
auto-incremented integer primary keys on their tables.
Maybe I'm just "old school" but I've always thought that you should choose a
primary key based on data that is actually in the table whenever po
his list to use
a
> primary key that actually contain somewhat meaningful data.
> I have always used primary keys solely for one purpose only: To identify
a
> table row uniquely, using auto incremental integers. Actually, if I were
to
> use a unique number in an application, I wou
Sorry guys,
I just learned that ctrl-return would send the email you are composing, so I
got cut off short, so let me try again :-/
It appears to be usual practice from what I can see in this list to use a
primary key that actually contain somewhat meaningful data.
I have always used primary
Hi everybody,
It appears to be usual practice from what I can see in this list to use a
primary key that actually contain somewhat meaningful data.
I have always used primary keys solely for one purpose only: To identify a
table row uniquely, using autoincremental integers. Actually, if I were
On Sunday 15 May 2005 20:31, Dan Bolser wrote:
> You must mean a multipart primary key with three parts :)
>
> or "multiple-column indexes"
>
> That is what I would do (use a multiple-column index (primary key) - its
> kinda based on opinion, but I think you should let the real data be the
> prima
>> What I want to ensure is that there are no duplicate records when
>considering the three foreign keys above. Would it be appropriate to remove
>the single primary and replace with three multiple primary keys? Is there a
>performance impact when doing this. this seems overly complex
ing the three foreign keys above. Would it be appropriate to remove
the single primary and replace with three multiple primary keys? Is there a
performance impact when doing this. this seems overly complex and wonder if
I should be breaking the table up to simplify? Any suggestions would be
appreciate
foreign keys above. Would it be appropriate to remove the single
primary and replace with three multiple primary keys? Is there a performance
impact when doing this. this seems overly complex and wonder if I should be
breaking the table up to simplify? Any suggestions would be appreciated.
Bob
At 9:10 +1000 4/21/05, Daniel Kasak wrote:
Daevid Vincent wrote:
If I have a table with a primary key like this:
CREATE TABLE `answers` (
`qid` INT UNSIGNED NOT NULL ,
`userid` INT UNSIGNED NOT NULL ,
`groupid` INT UNSIGNED NOT NULL ,
`comments` TEXT NOT NULL ,
PRIMARY ( `qid` , `userid` , `groupi
Daevid Vincent wrote:
>If I have a table with a primary key like this:
>
>CREATE TABLE `answers` (
>`qid` INT UNSIGNED NOT NULL ,
>`userid` INT UNSIGNED NOT NULL ,
>`groupid` INT UNSIGNED NOT NULL ,
>`comments` TEXT NOT NULL ,
> PRIMARY ( `qid` , `userid` , `groupid` )
>);
>
>But I will also be s
If I have a table with a primary key like this:
CREATE TABLE `answers` (
`qid` INT UNSIGNED NOT NULL ,
`userid` INT UNSIGNED NOT NULL ,
`groupid` INT UNSIGNED NOT NULL ,
`comments` TEXT NOT NULL ,
PRIMARY ( `qid` , `userid` , `groupid` )
);
But I will also be searching in various pages, for all
Hello.
> So in this case MySQL will choose to use the largest index that suits
MySQL will choose index which returns less rows.
> Given the high cardinality of `manufacturer`
Cardinality - the number of unique values in the index. So manufacturer
index usually has low cardinality and k
Gleb Paharenko wrote:
Hello.
If you have a separate indexes on section and status columns, MySQL
will use only one of them. And as the column status has very small number
of possible values the cardinality of separate index on it will be too low
and optimizer won't use this index. I think, if slow
Hello.
If you have a separate indexes on section and status columns, MySQL
will use only one of them. And as the column status has very small number
of possible values the cardinality of separate index on it will be too low
and optimizer won't use this index. I think, if slow updates won't be
Hiya,
I've been trying to find out about this for a few days, but can't seam
to find much information about it on the web.
At the moment I've got a few tables, one of this looks like:
CREATE TABLE `news` (
`section` TINYINT UNSIGNED ZEROFILL NOT NULL,
`article` SMALLINT(4) NOT NULL AUTO_INCRE
ta from another and finding that the
server is doing a table scan on the second table, even though it's a
simple join on the primary keys. This doesn't seem right. The query
looks liket this:
UPDATE a SET a.y TO b.a WHERE a.primary_key = b.primary_key
and if I do the equivalent SELECT
ta from another and finding that the
server is doing a table scan on the second table, even though it's a
simple join on the primary keys. This doesn't seem right. The query
looks liket this:
UPDATE a SET a.y TO b.a WHERE a.primary_key = b.primary_key
and if I do the equivalent SELECT
I'm updating one table with data from another and finding that the
server is doing a table scan on the second table, even though it's a
simple join on the primary keys. This doesn't seem right. The query
looks liket this:
UPDATE a SET a.y TO b.a WHERE a.primary_key = b.prima
I disagree with your LEFT JOIN/RIGHT JOIN results.
SELECT
activenodes.name,lrsrc.lid,activelayers.rsrcc,lrsrc.rsrc,nrsrc.rsrc
FROM activelayers
LEFT JOIN lrsrc ON lrsrc.id=activelayers.id AND
lrsrc.lid=activelayers.lid
RIGHT JOIN nrsrc ON lrsrc.rsrc=nrsrc.rsrc
RIGHT JOIN activenodes ON
On Oct 29, 2004, at 6:26 AM, [EMAIL PROTECTED] wrote:
I think it may be because of your mixed left and right joins. There
are several bugs listed that show that the optimizer mishandles
certain combinations of left and right joins.
SELECT
activelayers.id,activelayers.lid,activelayers.rsrcc,
=nrsrc.rsrc)
> as matchcount,activenodes.name,activenodes.rsrcc
> FROM activelayers
> LEFT JOIN lrsrc ON lrsrc.id=activelayers.id AND
lrsrc.lid=activelayers.lid
> RIGHT JOIN nrsrc ON lrsrc.rsrc=nrsrc.rsrc
> R
rc ON lrsrc.id=activelayers.id AND lrsrc.lid=activelayers.lid
> RIGHT JOIN nrsrc ON lrsrc.rsrc=nrsrc.rsrc
> RIGHT JOIN activenodes O
tivenodes.rsrcc
FROM activelayers
LEFT JOIN lrsrc ON lrsrc.id=activelayers.id AND lrsrc.lid=activelayers.lid
RIGHT JOIN nrsrc ON lrsrc.rsrc=nrsrc.rsrc
RIGHT JOIN activenodes ON nrsrc.id=activenodes.id
GROUP BY activelayers.id,activelayers.lid,activenodes.id
HAVING matchcount=activelayers.rsrcc
OR
1582
for a better explanation.
Yours,
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"Rui Monteiro" <[EMAIL PROTECTED]> wrote on 07/20/2004 01:02:36 PM:
> Hello,
>
> The example I gave you has 2 foreign keys that are primary keys on that
table.
>
should have only one Primary Key.
Yours,
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"Rui Monteiro" <[EMAIL PROTECTED]> wrote on 07/20/2004 11:54:00 AM:
> Mello,
>
>
>
> I was wondering why canto r how can I put 2 primary keys on a table?
Mello,
I was wondering why canto r how can I put 2 primary keys on a table?
Here's na example on Oracle language:
CREATE TABLE FacturaMusica(
CodFactura number(4), CONSTRAINTS FK_FacturaMusica_CodFactura
FOREIGN KEY(CodFactura) REFERENCES Factura(CodFa
w in set (0.00 sec)
>>From: Egor Egorov <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Primary keys
>>Date: Wed, 24 Mar 2004 13:28:58 +0200
>>
>>"JOHN MEYER" <[EMAIL PROTECTED]> wrote:
>> > Is there a way to do a SQL Select a
So I can do something like "SELECT * FROM " . $tablename . "WHERE _rowid="
$id (I'm using PHP and the primary key is a unique integer column in each of
the tables).
From: Egor Egorov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Primary keys
Date: Wed, 2
"JOHN MEYER" <[EMAIL PROTECTED]> wrote:
> Is there a way to do a SQL Select and get a record without specifying the
> primary key. Example. I have two tables CANDLE and VOTIVES. Can I define
> a select that says "SELECT * FROM TABLE WHERE PRIMARY_KEY="...
>
No, You can't.
Only if PRIMARY or
Is there a way to do a SQL Select and get a record without specifying the
primary key. Example. I have two tables CANDLE and VOTIVES. Can I define
a select that says "SELECT * FROM TABLE WHERE PRIMARY_KEY="...
John Meyer
_
FREE
I solved it myself :)
You need to keep the primary keys in the same order as the index, DOH!
ofcourse :)
In parant table
PRIMARY KEY(key1,key2)
In child table
INDEX(key_fk1, key_fk2)
Regards
/Jonas
- Original Message -
From: "Jonas Lndén" <[EMAIL PROTECTED]>
To: &
Hello, I am banging my head against the wall trying to figure out how to construct a
foreign key towards a table with a primary key consisting of two columns. I have been
googling around and thought this would work, but it just gives me an ERROR 1005.
ALTER TABLE testDB ADD FOREIGN KEY (fkey1, f
Hmmm... I fixed the problem but I still don't know what caused it. That same query now
produces the below EXPLAIN result and now
runs 70% faster.
I ran OPTIMIZE TABLE on Spells and Classes, that made Spl rows 1, then I forced the
Cls table to use the Object index and it worked.
Now, I can't get
Hi, I'm not sure I understand indexes properly.
In this EXPLAIN, I expected the Cls (Classes) table to be of type ref with
the key being ObjectID. I'm joining both identically as far as I can tell,
on one of the columns in the primary key, which is set to a key itself, but
Cls is joining on ALL. W
onday, October 20, 2003 2:34 PM
To: [EMAIL PROTECTED]
Subject: Re: Newbie - Primary Keys
Good points Patrick. Thanks for the follow-up :-)
--- Patrick Shoaf <[EMAIL PROTECTED]> wrote:
-
Mark is correct, you can define only 1 Primary Key,
but the primary keycan be
u need multiple indexes, or do
you need 1 indexwith multiple data fields.
At 02:07 PM 10/20/2003, Mark V wrote:
Hi Carlos,
You can't have 2 primary keys. A table can only have
one primary key. You can, however, also define a
Unique key, and if you set it up such that it is not
null, it will act
BTW Carlos,
I'm not sure why you would want or need two primary
keys in a table, but if find you truly do (as opposed
to a PK and some other unique index/key) - there is
probably something wrong with your database design.
You may need to rethink your design. Do some research
and reading o
Hi Carlos,
You can't have 2 primary keys. A table can only have
one primary key. You can, however, also define a
Unique key, and if you set it up such that it is not
null, it will act much like a prmary key:
CREATE TABLE test
( id1 INT UNSIGNED NOT NULL,
PRIMARY KEY (id1),
id
Hi all!
Just wanted to know how do I create a table with two primary keys.
Thanks a lot!
" <[EMAIL PROTECTED]>
Sent: Wednesday, 04 June, 2003 18:54
Subject: Re: MySQL: standard SQL compliancy: primary keys: default: should be
NOT NULL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Becoming Digital wrote:
[snip]
> from http://www.mysql.com/doc/en/CREATE_TABLE.html:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Becoming Digital wrote:
[snip]
> from http://www.mysql.com/doc/en/CREATE_TABLE.html:
> a.. A PRIMARY KEY is a unique KEY where all key columns must be
defined as NOT
> NULL. If they are not explicitly declared as NOT NULL, it will be done
> implicitly
Hi,
We agree that statements of the form
CREATE TABLE table-name (column1 INT PRIMARY KEY)
should be legal -- it should not be necessary to say
CREATE TABLE table-name (column1 INT PRIMARY KEY NOT NULL)
The requirement, that primary keys should explicitly be
declared as NOT
I'm unsure what you see as a problem here? The only conflict with relational
theory would occur if MySQL *permitted* NULL values in primary keys. According
to the error message you received, MySQL is doing a fine job of preventing this.
CREATE TABLE test (
col1 INT PRIMAR
e primary
> key is not explicitly set to NOT NULL then the RDBMS should automatically
> and silently assume the user means NOT NULL. After all, any half decent
> book on relational databases out there will tell you that primary keys
> cannot be null. So why does MySQL do it this way. B
Daniel Kasak wrote:
Neil Zanella wrote:
SQL92, AFAIK, specifies that if the primary
key is not explicitly set to NOT NULL then the RDBMS should
automatically
and silently assume the user means NOT NULL.
Sounds like the end of the world to me ;)
I suppose you have to get excited about something..
, June 04, 2003 12:03 AM
Subject: MySQL: standard SQL compliancy: primary keys: default: should be
NOT NULL
Hello,
I believe that MySQL is in error in reporting the following message just
because I did not specify that the PRIMARY KEY should not be NULL. These
days there are standards and
RDBMS should automatically
and silently assume the user means NOT NULL. After all, any half decent
book on relational databases out there will tell you that primary keys
cannot be null. So why does MySQL do it this way. By doing this MySQL is
breaking the portability of my standard SQL code which works
automatically
and silently assume the user means NOT NULL. After all, any half decent
book on relational databases out there will tell you that primary keys
cannot be null. So why does MySQL do it this way. By doing this MySQL is
breaking the portability of my standard SQL code which works so well with
On Wed, Nov 13, 2002 at 05:03:38PM -0200, Silmara wrote:
> I'm working with MySQL-Innodb and I have one table with primary key composed
> by the 5 first fields, and I want to change this removing the primary keys
> attributes and add one new field in the first position as p
1 - 100 of 145 matches
Mail list logo
