I want to design a database for lots of users. Each user will be
managing their own messages. Does it make sense to create a table
for each user after they've registered?
Or should I just create one MESSAGES table and store messages there
keyed off of their user_id?
If I create a table
I want to design a database for lots of users. Each user will be managing
their own messages. Does it make sense to create a table for each user after
they've registered?
Or should I just create one MESSAGES table and store messages there keyed off
of their user_id?
If I create a table for
: Database design question
I want to design a database for lots of users. Each user will be managing
their own messages. Does it make sense to create a table for each user
after they've registered?
Or should I just create one MESSAGES table and store messages there keyed
off of their user_id?
If I
referencing the destinating user as well.
-Original Message-
From: James Tu [mailto:[EMAIL PROTECTED]
Sent: Monday, August 07, 2006 1:56 PM
To: mysql@lists.mysql.com
Subject: Database design question
I want to design a database for lots of users. Each user will be
managing
their own
@lists.mysql.com
Sent: Monday, August 07, 2006 4:11 PM
Subject: Re: Database design question
Thanks everyone.
Now I feel confident that one table will be fine (Tripp's stat of
30 million records put me at ease :) ).
Cheers,
-James
On Aug 7, 2006, at 4:08 PM, John Meyer wrote:
One table,
USERS
On 8/7/06, James Tu [EMAIL PROTECTED] wrote:
If I create a table for each user (I can potentially have hundreds of
thousands of users), will MySQL be able to handle this?
If I just have one table, I could potentially have millions of
records in one table. Will MySQL be able to handle this?
I have four different activities. Each has its own set of data that
I want to save. So, I made four different tables to hold the saved
data. Each record also has 'keywords' field (essentially this is the
only field that all tables have in common.)
Later on, I want to search all the keywords
james tu [EMAIL PROTECTED] wrote on 04/26/2005 12:06:34 PM:
I have four different activities. Each has its own set of data that
I want to save. So, I made four different tables to hold the saved
data. Each record also has 'keywords' field (essentially this is the
only field that all
I tried that and maybe I'm doing something wrong but...
-I have to select the same number of columns...for each UNION
-And each of the records from the union fall under the same column
headings as the first SELECT...
I even tried to define column aliases..
SELECT `running` as `running_blah`...
If you posted your actual table structures (SHOW CREATE TABLE xx\G) I
think I could be more helpful. Right now I am just shooting in the dark.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
James [EMAIL PROTECTED] wrote on 04/26/2005 02:15:49 PM:
I tried that and
I haven't created real project tables yet.
But here are the test ones that I'm experimenting with.
CREATE TABLE east (
id int(11) NOT NULL auto_increment,
keywords varchar(255) default NULL,
east_1 varchar(255) default NULL,
PRIMARY KEY (id)
) ;
CREATE TABLE north (
north_id int(11) NOT
Hello,
I have two questions:
I would like to know whether I am violating the principle of atomicity in
doing the following:
I have a form which has a field with the following options: Choice1, choice2
and choice3.
Each of the above choices have two further subchoices : subChoice1,
subchoice2.
Mahmoud,
Are these values atomical?
My other question is what are the repercussions of
not putting a table in 2nd and 3rd Normal Form.
Your 'choice1-subchoice1' etc are combined values, so they aren't
atomic. From your three example dropdown values, it looks as if
'choice' and 'subchoice'
Hi all,
I have some doubts about how to implement this kind of scenario:
I have a table of elements in cronological order, let's call it table A:
for every A element, I have a number of elements ordered on a
progressive number.
This could be a simply one-to-many relation, where I can handle a
I think you need to explain what kind of SELECTs you want to do, and what
results you expect. How do you expect to get results from a SELECT which
returns hits in both the B and C tables? If you expect to do this, then
the D table is probably your correct answer. Do you really need a rec_type
Il giorno 11/ott/04, alle 11:53, [EMAIL PROTECTED] ha scritto:
I think you need to explain what kind of SELECTs you want to do, and
what
results you expect.
you're right, I'll try to explain it better
I'm working on a system that must keep track of all the music
broadcasted by a tv,
so, let's
My answers interspersed below (and yes, I have read his follow up reply
that had additional information)
Giulio [EMAIL PROTECTED] wrote on 10/11/2004 05:44:43 AM:
Hi all,
I have some doubts about how to implement this kind of scenario:
I have a table of elements in cronological order,
Hi,
I'm writing a database for an online candle store. Here's the situation. This store
sells all sorts of items including candles. Now the gist is that some of the candles
can be made in different types of waxes and some only have one wax. My question is
how do I resolve this when I write
JOHN MEYER [EMAIL PROTECTED] wrote on 07/04/2004 15:39:10:
Hi,
I'm writing a database for an online candle store. Here's the
situation. This store sells all sorts of items including candles.
Now the gist is that some of the candles can be made in different
types of waxes and some
Everything I've read about creating online stores is that you are
selling inventory items, not the items that makeup the inventory item.
So if you sell a red candle made from wax X, candle is the product and
red wax X are two attributes of the product.
Ideally your structure would work for any
design question
Hi,
I'm writing a database for an online candle store. Here's the situation.
This store sells all sorts of items including candles. Now the gist is that
some of the candles can be made in different types of waxes and some only
have one wax. My question is how do I resolve this when
Message-
From: James Walters [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 9:42 AM
To: [EMAIL PROTECTED]
Subject: Basic Database Design Question
Hello,
DB novice checking in here with a basic design
question. I have a table called 'nms_apps' which
stores information about
Hello,
DB novice checking in here with a basic design
question. I have a table called 'nms_apps' which
stores information about all of our applications which
we have developed/maintained for our client. One
column which I would like to use is called 'used_by',
which would store information
Phone/fax: (408) 904-7198
[EMAIL PROTECTED]
-Original Message-
From: James Walters [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 10:42 AM
To: [EMAIL PROTECTED]
Subject: Basic Database Design Question
Hello,
DB novice checking in here with a basic design
question. I
29, 2003 9:42 AM
To: [EMAIL PROTECTED]
Subject: Basic Database Design Question
Hello,
DB novice checking in here with a basic design
question. I have a table called 'nms_apps' which
stores information about all of our applications which
we have developed/maintained for our client. One
column
Hello... I am currently working on a User Account Management
system. I am actually a Unix SA who is moonlighting at work as a MySQL
DBA and web developer. I am learning a lot and enjoying the work, but I am
severely lacking in database design fundamentals. I have created a couple
very
[snip]
Let's say that I have users Mary, Joe, Frank, and Dan. I also have
servers panther, cheetah, jaguar and lion. The data for each account that I
want to maintain is UID, GID, home directory, and default shell.
In designing a table or tables to handle this example what can I
make as a
On 18-Jun-2003 NIPP, SCOTT V (SBCSI) wrote:
Hello... I am currently working on a User Account Management
system. I am actually a Unix SA who is moonlighting at work as a MySQL
DBA and web developer. I am learning a lot and enjoying the work, but I
am
severely lacking in database
I am fairly new to this, so please bare with me on this.
I am designing a database that stores information about the computers I
manage, and am developing a PHP front end to add, view, and edit information
about the computers. One issue I ran into is designing the hard drive
information. Some
Hi all,
I am in the process of designing a MySQL database that will run on Redhat
7.1, but I am fairly sketchy on MySQL and performance.
What I want to do is have a database that keeps track of large distribution
lists. Each list has a unique ID, an owner (which is a reference to an ID in
On 3/28/02 1:39 PM [EMAIL PROTECTED] wrote:
What I want to do is have a database that keeps track of large distribution
lists. Each list has a unique ID, an owner (which is a reference to an ID in
another table) and a creation date.
My question is this: Would it be more efficient to have
-Original Message-
From: Ben Holness [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
...
My question is this: Would it be more efficient to have each entry in the
list stored in this table in the database, or would I be better
off having a
reference to a file that is
Hi Ben:
Performance would definitely be better if you store the data in the
database as opposed to simply storing references to files. Sounds like you
could solve this with 2 tables with one for the actual lists (assuming the
structure of all your list is the same) and the other for the list
Hi Chris/Nick/Scalper,
Thanks for the replies. I am not too sure how to implement this in tables,
so I will give an example:
Let's say I have three lists - a,b and c. List a contains 10,000 entries,
list b contains 2,500 entries and list c contains 75,000 entries.
I have a table of lists, with
In your situation (or any situation, IMHO),
multi-value fields defeat the purpose of good database
design.
I think you are on the right track if you are willing
to tolerate a little redundancy for the sake of
simplicity (as a one-to-many relationship). If you
really want to structure it as a
Nick,
This is pretty familiar to me because I'm analyzing the behavior of
people
in on-line discussions, so I'm gathering such data.
Which begs the questions:
- in what way are you analyzing behavior? and
- in what way are you analyzing this list-community?
=dn
MySQL list busting
-Original Message-
From: DL Neil [mailto:[EMAIL PROTECTED]]
...
Which begs the questions:
- in what way are you analyzing behavior? and
- in what way are you analyzing this list-community?
There's too much to read, is the simple answer to the first question.
Over the last few
Thanks very much to every who helped me with my MySQL problem!
I will probably go with the three table solution as it also eliminates the
need for yet another table!
Cheers,
Ben
-
Before posting, please check:
On Saturday 28 July 2001 15:09, Scott Goldstein wrote:
I'm new to MySQL and database design and I have a questions concerning
entities with common attributes.
Suppose I have two entities, foo and bar with the following attributes:
foo: (id, A, B, C, D, F)
bar: (id, A, B, C, X, Y)
Well, I
Hello,
I have a table design question relating to best practice and performance.
Monthy is somewhat of a SQL guru and so may be many others on this list,
this may actually help a lot of folks out there:
Example:
I want to get a listing of all applicable rates for a delivery:
a rate can be
Design Question
Hello,
I have a table design question relating to best practice and performance.
Monthy is somewhat of a SQL guru and so may be many others on this list,
this may actually help a lot of folks out there:
Example:
I want to get a listing of all applicable rates for a delivery:
41 matches
Mail list logo
