On Thu, Sep 17, 2009 at 3:46 AM, John Meyer john.l.me...@gmail.com wrote:
Alternatively, you can skip the A_ID and have a compound key of USER_ID and
A_NUMBER on the ASSOC_NUMBERS table. I prefer the A_ID, though.
Note that this would be marginally faster, because all your data is in
the index,
Johan De Meersman wrote:
On Thu, Sep 17, 2009 at 3:46 AM, John Meyer john.l.me...@gmail.com wrote:
Alternatively, you can skip the A_ID and have a compound key of USER_ID and
A_NUMBER on the ASSOC_NUMBERS table. I prefer the A_ID, though.
Note that this would be marginally faster,
Hi folks --
What would be the right approach in MySql 5.0?
My table, USERS, has columns NAME and IP. Associated with each user is also a
collection of from 0 to 50 INTs. What's a reasonable way to put these 50 INTs
in the table without using 50 separate columns, INT01...INT50? Is BLOB an OK
Pete Wilson wrote:
Hi folks --
What would be the right approach in MySql 5.0?
My table, USERS, has columns NAME and IP. Associated with each user is also a
collection of from 0 to 50 INTs. What's a reasonable way to put these 50 INTs
in the table without using 50 separate columns,
Be careful about burying list type of data in a column.
I've seen poor performance issues parsing lists and XML type data
buried in columns.
A lot depends on your application and how and what you need to query
from those lists.
I've seen a case where a submitted documents were stored in a column
Pete wrote:
Hi folks --
What would be the right approach in MySql 5.0?
My table, USERS, has columns NAME and IP. Associated
with each user is also a collection of from 0 to 50 INTs.
What's a reasonable way to put these 50 INTs in the table
without using 50 separate columns,
Pete Wilson wrote:
Break them out into a separate table linked via the primary
key.
How elegant! Thanks.
-- Pete
it's nothing not taught in Database Design 101. Typically you would
have a setup like this
USERS
USER_ID --primary key
USER_NAME
USER_IP
ASSOC_NUMBERS
A_ID