On 9/1/2010 11:47 AM, Tompkins Neil wrote:
I do have a tabled which contains both the managers_id and teams_id for the
current teams managed. I think by adding the managers_id alongside the
fixture_result table will then allow me to find which points the manager
has accumulated alongside which f
I do have a tabled which contains both the managers_id and teams_id for the
current teams managed. I think by adding the managers_id alongside the
fixture_result table will then allow me to find which points the manager
has accumulated alongside which fixtures and teams.
Cheers
Neil
On Wed, Sep
I strongly suggest that you make a separate table for the manager <-> team
relationship, so you can keep a history. Put a date-stamp in there. This might
come in handy as you get further into your design.
I ran into this problem when one of our sales reps moved from one office to
another, and t
Hi Neil,
May be your question is too vague.
You have already identified the 'real world' objects that you want
represented in the database.
Have you identified the specific pieces of information that you want stored
for each object ? After you do that, you can then start to see what the
relation
Hi there,
I know you would like just a solution, but I want to give you just a little
bit of background.
Think in real life things(entities), think as you would have to do it on
paper.
[1]
You said you have:
managers, teams players and fixtures/results (matches)
these are your tables
plus...
>-Original Message-
>From: AndrewJames [mailto:andrewhu...@gmail.com]
>Sent: Saturday, September 12, 2009 1:20 AM
>To: Kyong Kim; Arthur Fuller
>Cc: Claudio Nanni; mysql
>Subject: Re: database design
>
>thank you all, i think
>
>"You probably wouldn&
directly."
>
> is my answer.
>
>
> --
> From: "Kyong Kim"
> Sent: Saturday, September 12, 2009 8:22 AM
> To: "Arthur Fuller"
> Cc: "Claudio Nanni" ; "AndrewJames"
> ; "mysql"
> Subject: Re:
Storing it directly will cause problems when you want to add a new Article
Type. IMO it's better to have an ArticleTypes table (AutoIncrement) and
store its values in the ArticleTypeID column in the Articles table.
A.
On Sat, Sep 12, 2009 at 1:19 AM, AndrewJames wrote:
> thank you all, i think
>
epter aucune responsabilité pour
le contenu fourni.
> Date: Fri, 11 Sep 2009 15:22:57 -0700
> Subject: Re: database design
> From: kykim...@gmail.com
> To: fuller.art...@gmail.com
> CC: claudio.na...@gmail.com; andrewhu...@gmail.com; mysql@lists.mysql.com
> > A) You
;Arthur Fuller"
Cc: "Claudio Nanni" ; "AndrewJames"
; "mysql"
Subject: Re: database design
A) You would probably want to populate the Article.Article_Type column
with Article_Type.ID. You probably wouldn't need Article_Type table if
you're going
A) You would probably want to populate the Article.Article_Type column
with Article_Type.ID. You probably wouldn't need Article_Type table if
you're going to store Article_Type value directly.
I would also consider the use of natural primary key vs surrogate
primary key. We've seen good results wi
I agree with Claudio. You have your design correct. The only other thing you
need is the uid qualifier. Presumably you are using PHP or some other front
end to present your data. Your front end would request the user's name and
password, saving the uid in a variable and then issuing the select with
A.J., It sounds good to me!
You can be a little confused but you did it well,
It seems you have all you need there.
A) Yes
B) select * from articles A left join article_types AT on A.article_type =
AT.article_types_id
Claudio
2009/9/11 AndrewJames
> This is a bit of a long shot, but i real
john.l.me...@gmail.com
Sent: Friday, September 04, 2009 6:09 PM
Subject: RE: Database design - help
> given the following table layouts
URLs:> URL_ID (primary key for URL)> URL_TEXT>> URL_CATEGORY> URL_ID
(key which points to URL.URL_ID)> CATEGORY_ID (key which
lworld.com ; mysql@lists.mysql.com
Cc: john.l.me...@gmail.com
Sent: Friday, September 04, 2009 6:09 PM
Subject: RE: Database design - help
> given the following table layouts
> URLs:> URL_ID (primary key for URL)> URL_TEXT>> URL_CATEGORY> URL_ID
> (key which
e ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
n seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> From: bobsh...@ntlworld.com
> To: mysql@lists.mysql.com
&
helpful to me.
cheers
- Original Message -
From: "John Meyer"
To: "BobSharp"
Cc:
Sent: Monday, August 31, 2009 4:56 PM
Subject: Re: Database design - help
BobSharp wrote:
As a complete newbie in MySQL, I need a database
to store URLs related to Tenpin Bowling
BobSharp wrote:
As a complete newbie in MySQL, I need a database
to store URLs related to Tenpin Bowling.
There are several Categories ... Equipment Manufacturers,
Organistations, (UK) ProShops, (UK) Bowling Centres, Personal
Websites, Misc., Coaching & Instructional websites, etc.
There
gned NOT NULL auto_increment,
`title` varchar(60) NOT NULL,
PRIMARY KEY (`title_id`),
UNIQUE KEY `title` (`title`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
Thanks for any continued support.
> From: John Meyer <[EMAIL PROTECTED]>
> Date: Wed, 23 May 2007 07:28:23
Normalization is about using ids to minimize change, which also eliminates repetition. It's fine to have the color "red" repeated
throughout your table as long as it will never change. But if you suddenly have two shades of red, you'll need to update all the
records that say "red". If you used id
Officelink wrote:
> Hi everyone,
>
> I¹m trying to set up a database with information that will be used in a
> garment slideshow in flash.
>
> The information to be included as part of the slideshow would be:
> code, optional title, description, colours, sizes, garment image, fabric
> swatch image
A lot depends upon the sophistication of the program you write to manage
this. I doubt there is any way to create something so sophisticated with
just SQL.
My first thought would be to use three tables. Make sure every user has a
unique use ID. The users' passwords would be stored in the table of
At 12:54 PM 12/16/2006, you wrote:
Hiya,
Real easy quick question.
I need to design a database which holds users with email, name and some
other details.
I also want each user to be able to create one or more groups of users,
owned by themselves.
What would be the best design approach?
So far
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?
;James Tu" <[EMAIL PROTECTED]>
To:
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
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
Another table
MESSAGES
With a foreign key referencing users.
Maybe a second foreign key r
One table,
USERS
Another table
MESSAGES
With a foreign key referencing users.
Maybe a second foreign key 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: Databa
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 e
OK, I think I got it now. Thanks for the additional info, that helps alot.
Rhino wrote:
- Original Message - From: "Mike Blezien" <[EMAIL PROTECTED]>
To: "MySQL List"
Sent: Friday, February 17, 2006 7:49 AM
Subject: Database design help
Hello,
we currently have a small database s
- Original Message -
From: "Mike Blezien" <[EMAIL PROTECTED]>
To: "MySQL List"
Sent: Friday, February 17, 2006 7:49 AM
Subject: Database design help
Hello,
we currently have a small database setup for affilates and visitor/leads.
I believe we have a "one to many" application, one
If you give this due consideration, you may find that a lot of your
problem evaporates and the rest gets simpler to handle.
Just a general observation made by a disinterested third party; ignore it
if you like :-)
Rhino
- Original Message - From: "Ian Klassen" <[EMAIL PROTECTED]
at important and could be omitted with
no important loss of functionality?
If you give this due consideration, you may find
that a lot of your problem evaporates and the
rest gets simpler to handle.
Just a general observation made by a
disinterested third party; ignore it if you like
:-)
:-)
Rhino
- Original Message - From: "Ian Klassen" <[EMAIL PROTECTED]>
To: "Marco Neves" <[EMAIL PROTECTED]>;
Sent: Friday, January 20, 2006 3:49 PM
Subject: Re: Database design help
Marco,
Thanks for your help. I created this example to try to simplify
you like :-)
Rhino
- Original Message -
From: "Ian Klassen" <[EMAIL PROTECTED]>
To: "Marco Neves" <[EMAIL PROTECTED]>;
Sent: Friday, January 20, 2006 3:49 PM
Subject: Re: Database design help
Marco,
Thanks for your help. I created this exa
Marco,
Thanks for your help. I created this example to try to simplify my real
world problem. Clearly I didn't provide enough detail. Keeping with my
example, essentially I'm looking at product details that change over
time. Let's say I'm keeping track of boxes. Over time, the color or si
Ian,
I'ld like to help you, but a more specific db design would depend on
more
specific description on your application needs.
What I can say is that you need to adapt your database to your reality.
What I got til now is that you need a product table, where you can
sto
Thanks Ed. That's another good idea. The consensus I'm getting is to
create one table that stores unchanging data about the product and another
that stores transaction details. The
problem I'm still having is how to efficiently handle more than one
changing value.
As an example, let's say I
I built my inventory system like this,
I have a products table that contains all the information specific to each
part, less the quantity, i.e. Part Number, Description, Vendor, Color, Weight,
SKU number, etc...
Then I have another table that is my Inventory Tranactions Log that is just the
At 06:27 PM 1/18/2006 +, Marco Neves wrote:
Hi,
Why don't you create two table:
* a product table, with the product discriptions, and other
product related
info (call it prod):
|ID|NAME|SOME|OTHER|FIELDS|
|1|ProdA|..|..|..|
|2|ProdB|..|..|..|
Ian Klassen <[EMAIL PROTECTED]> wrote on 01/18/2006 01:09:55 PM:
> Hi all,
>
> I'm trying to figure out a solution to the following problem.
>
> Let's say I have a store with various products. I take inventory of
these
> products on different days. At any given time I want to view what the
Hi,
Why don't you create two table:
* a product table, with the product discriptions, and other product
related
info (call it prod):
|ID|NAME|SOME|OTHER|FIELDS|
|1|ProdA|..|..|..|
|2|ProdB|..|..|..|
* a stock movements table, with moviments by p
Matthew Lenz wrote:
anyone using openoffice:base to design mysql db's? back when I tried it
earlier this year it wasn't able to define relationships which made it
pretty much useless as a time saving tool.
Hi Matt,
Although it's slightly OT here, there is still a lot of development
going on
lied,
Reema
-Original Message-
From: Gordon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 01, 2005 8:39 AM
To: 'rtroiana'
Subject: RE: Database design query
I know what you are trying to do and I can see the logic advantage of having
a single table that defines the the gr
IF GroupID, HostID and UserID are unique between the three sets then your
GroupMember table will work although I would still be tempted to add a
MemberType in the GroupMember table.
Isn't MemberID the Foreign Key to UserID/HostID/GroupID althugh I don't know
if you can have three different foreig
Hi,
i think you must normalize your table to more than one table.
Users/Groups : N:1
Groups/Groups : N:1
Table Users :
User_id
Host
Group_id
Table Groups :
Group_id
Group_parent_id<- is a another group_id
No data redondancy and robust implementation.
see for example /etc/passwd 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
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 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`...
-J
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
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'
Big post = long response. Thank you for your patience.
When it comes to DB design I like to first identify the basic objects:
List owners (the people who manage a group), subscribers (the people in
the group), and the groups themselves. I think you equate a list owner to
a "User" of your servic
* Brian Reichert
[...]
> I don't know if there's a limit at to how many tables can be handled
> by a single MySQL query.
This limit is actually hardware architecture dependant: You can join 31
tables on a 32-bit server and 63 tables on a 64-bit server.
--
Roger
--
MySQL General Mailing List
Fo
On Mon, May 10, 2004 at 09:49:31PM -0700, Scott Haneda wrote:
> Sorry for the post again, I hijacked a thread and wanted to get this on the
> correct track.
>
> I can not seem to find the section in the manual that talks about the max
> number of tables MySql can use, can someone point me please?
I'm not sure what the maximum number of tables are per database (512?
1024?), but I wouldn't split your data unless you really have to. 70
million records may seem like a lot for a table, but it's really not.
Especially if the physical size of your data is small. Tables with
billions of records
Scott Haneda wrote:
I can not seem to find the section in the manual that talks about the max
number of tables MySql can use, can someone point me please?
I have been asked to build a database which could have some potentially
interesting storage needs.
There will be a users table, there can be x u
Man 3 times same thread !
What I could consider to you, I don't really understand what you are getting
at, what is wrong with 1000 users firstly ? And in the entry table store
their userID which is stored in a session when they login ? So when they
enter in data it stores their userID into a colum
Scott Haneda wrote:
If users become day 1000 and each of those users has 70,000 user_contacts,
that would be 70,000 * 1000 total records in one table, as users grow, this
becomes perhaps too many records in one table. Or at least the potential
for it.
My next option would be to make a new table
I'm not 100% sure as to what you are trying to do, however, the relationship
you describe could, I believe, be modeled as:
Candles (candleid, description, price)
Waxes (waxid, name/description)
Candle_Waxes (candleid, waxid)
Thus one table holds the description and price of each candle, another t
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 p
"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
>I have an question about the design of a database. What is the best way
>to design tables. Is it better to create many small tables, or create
>fewer big tables. Which of those two options will get the best performance?
If you are asking whether to store the data all in one big table or a bunc
Alex croes said:
> I have an question about the design of a database. What is the best
> way to design tables. Is it better to create many small tables, or
> create fewer big tables. Which of those two options will get the
> best performance?
Don't worry about performance. If performance is real
Duke, Brian wrote:
Can someone explain a 1:n non identifying relation?
Brian Duke
Yes.
I'm Dan, and I'm unique; there's only one of me.
However if I like a store after an initial purchase from them, I may go
back and another purchase.
1:n
User:Purchase
Dan
--
MySQL General Mailing List
F
Message-
From: Brent Baisley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 9:01 AM
To: Meli Meli
Cc: [EMAIL PROTECTED]
Subject: Re: Database-design
Why would you created separate fields for each quarter?
Create a field
called quarter and store a number in it. You could also comb
e bitwise section of the java
certification exam I have ever used
> -Original Message-
> From: Brent Baisley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2003 9:01 AM
> To: Meli Meli
> Cc: [EMAIL PROTECTED]
> Subject: Re: Database-design
>
>
x x
> > x xx x
Ladies and Gentlemen, the first real use of the bitwise section of the java
certification exam I have ever used
> -Original Message-
> From: Brent Baisley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, N
Why would you created separate fields for each quarter? Create a field
called quarter and store a number in it. You could also combine year,
month and day into a date field, which would make it easier to search
on ranges.
So, I think your table should look like this:
id
quarter
eventdate
week
O
you need to normalize your database structure, and create an ER diagram
based on that.
On Tue, 11 Nov 2003, Meli Meli wrote:
>
> I have a table with following structure:
>
> Id
> first quarter
> second quarter
> third quarter
> last quarter
> year
> month
> week
> day
>
> On an entry not all fie
> On an entry not all fields of the four quarter fields are covered with
> values. Following combinations are possible:
Why don't you just use one extra column (apart from whatever other
data you are storing) with that column being a date field. Then, you
can determine what data is part of w
by 4 bytes number (as 1 field) , you can keep 32 bits (criteria). this shows
how much you can save the space. but if the database is not huge, it's
better to select simpler solution (one field for one criteria). this is an
example in MySQL manual to show how to work with bits:
The following shows
Lee,
> I get the feeling there is a more efficient method using
> binary operations
> (only one field populated with zeros and ones) but I can't
> find anything to
> help in the manuals.
i think you should try to avoid such thing as much as you can.
Storing more than one piece of data in a colu
Lee.
Maybe others would disagree but they way I would handle this would be to
forget about storing the data in separate fields (or binary fields) and use
three tables.
Table1 - Facilities
A complete list of all criteria you want to record about the hotels
Table2 - Hotels
Table containing the hot
Hi,
I would create one field (char(200) or char(255)) for all criteria.
After that I will store:
in the first byte of that string Y if hotel has swimming pool, N - doesn't
have, Q - no idea
in the second byte of that string Y if hotel has TV, N - doesn't have, Q -
no idea
in the third byte of that
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 databa
[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
I don't enjoy being a PITA but could you teach your MUA to create
proper attributions? This makes it really hard to tell who said
what, leads to confusion, and may piss of quite a few people if a
debate gets somewhat heated...
# [EMAIL PROTECTED] / 2003-04-02 18:18:17 +0200:
> > #
I mean, at least that's how I reacted upon reading..
"
For MyISAM tables, you can work around the lack of ON DELETE by adding
the appropriate DELETE statement to an application when you delete
records from a table that has a foreign key. In practice this is as
quick (in some cases quicker) and much
# [EMAIL PROTECTED] / 2003-04-02 17:37:26 +0200:
> And from this page:
> http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
> I understand it is rather recommended NOT to use foreign keys, at least
> until mysql integrates it more fully.
which part of that page makes you say that?
--
Fr
Thank you for your explanations, after 4 interventions I now know much
more about the difference between primary, unique, index and I've learnt
that foreign keys exits in my sql ;-)
And from this page:
http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
I understand it is rather recommended NO
X-Mailer: Microsoft Outlook, Build 10.0.2616
your MUA wrap-mutilates quoted text.
# [EMAIL PROTECTED] / 2003-04-02 02:34:01 +0200:
> > 1. If a column is a primary key, there is no need to declare it a
> > unique.
>
> Thank you, I was doing that for every table sinc
Peter,
>1. If a column is a primary key, there is no need to declare it a
unique.
Thank you, I was doing that for every table since I started.
>2. Without foreign keys, your CREATE statements don't reveal table
relationships.
I am surprised, I thought my SQL is not a proper relationnal database
a
Damien,
1. If a column is a primary key, there is no need to declare it a unique.
2. Without foreign keys, your CREATE statements don't reveal table
relationships.
3. The best way I know to validate a schema is to (i) write or draw all the
application's use cases, (ii) from the use cases derive
# [EMAIL PROTECTED] / 2003-03-30 17:49:27 +0200:
> Hello, I was starting a php/mysql project in december and seeked for help on
> this mailing list, it has been a great help for solving problems.
> My application is a website where you can order meals from restaurants that
> are within your postcod
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:
http://www.my
> -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 las
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
---
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 many
> -Original Message-
> From: Ben Holness [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 28, 2002 7:43 AM
> Have I understood the two table concept correctly?
> How does the third table fit in?
>
> I guess that if two (or more) of the entries overlap, I could make things
> even
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
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
> -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 tha
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
i got a really good book on MySQL, it does not have much in the way of
troubleshooting, but a lot on use.
Title: MySQL
Author: Paul DuBois
ISBN: 0-7357-0921-1
Publisher: New Riders
-
Before posting, please check:
http://w
w.cbweb.net
[EMAIL PROTECTED]
- Original Message -
From: "Jindo Soul" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 11, 2001 2:43 PM
Subject: Re: Database Design
> Hi All,
>
> Not really a MySQL-oriented question. But this board'
Hi All,
Not really a MySQL-oriented question. But this board's so active I decided to post my
question here in hope I'll get some lights on my database design.
Using Amazon as an example, say if I have a table that stores user information and
each user is assigned an unique id (field might lo
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)
We
I am sure this has been recommended on this list before, but here it goes:
One very good book to read regarding theory is: Database Design for Mere
Mortals by Michael Hernandez, it sits along with Paul DuBois' book on my
night table. I don't think you can pick a better combination to teach
yoursel
D]>, "[EMAIL PROTECTED]"
><[EMAIL PROTECTED]>
>Subject: Re: database design
>Date: Tue, 19 Jun 2001 13:54:58 -0400
>
>Alot of it would depend on what exactly you are doing. If you have alot of
>small
>tables with only 3 columns(I'm assuming thats w
Alot of it would depend on what exactly you are doing. If you have alot of small
tables with only 3 columns(I'm assuming thats what you meant) that can make for a
messy server when it starts getting hit by a demand. Also, there are lots of good
books on database design. Que generally has made so
1 - 100 of 104 matches
Mail list logo
