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't need the PKs.
Hi James,
An internal, unique, auto-increment PK is a good idea on dynamic, large
tables. Smaller, mostly static, tables can often do without a PK. In a
backend DB it's a godsend. What would happen if I depended on the
programming in the client-side code to handle the PK?? It would be
impossi
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:
Hi Rhino,
Excellent question. Felt as you do, initially.
Here's what changed my mind.
Integer keys are fast. And small. Hence, they take very little RAM space.
They are contiguous. A missing PK is easy to find. There's a gap in the
number sequence.
Can't do this with the part description. No
Hi,
Normalizing some tables.
Does it make much difference to MySQL whether I separate minor, related data
into tables for a main account (MemberAccount) such as:
MemberAccount then emails, religion, hobbies, education, etc. I'll explain.
On the other hand, I could put all the information in
Hi all,
I have removed mysql 4_0_20d and installed 4.1.
My puzzle is this:
1. I have prior databases in 4.0 (intact data directory with InnoDB files
*.idb, etc.) data directory with sub directories.
2. I want to bring in some of the databases to the new 4.1 version.
The 4.0 databases
Here's is your test reply.
Wishing you complete success...
Ken
Sugar Creek
- Original Message -
From: "Robb Kerr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 14, 2004 11:34 AM
Subject: Test post to test new client
I'm posting to test a new newsgroup client. Pleas
