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
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
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
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,
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
...@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 points to
CATEGORY.CATEGORY_ID) SUBCATEGORY_ID
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
CC: john.l.me...@gmail.com
Subject: Re: Database design - help
Date: Fri, 4 Sep 2009 16:24:22
; 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 points to URL.URL_ID) CATEGORY_ID (key which
be helpful to me.
cheers
- Original Message -
From: John Meyer john.l.me...@gmail.com
To: BobSharp bobsh...@ntlworld.com
Cc: mysql@lists.mysql.com
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
facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
From: bobsh...@ntlworld.com
To: mysql@lists.mysql.com
CC: john.l.me...@gmail.com
Subject: Re: Database design - help
Date: Fri, 4 Sep 2009 16:24:22 +0100
Hi
Thanks
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
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
- Original Message -
From: Mike Blezien [EMAIL PROTECTED]
To: MySQL List mysql@lists.mysql.com
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
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 mysql@lists.mysql.com
Sent: Friday, February 17, 2006 7:49 AM
Subject: Database design help
Hello,
we currently have a
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
PROTECTED]
To: Marco Neves [EMAIL PROTECTED]; mysql@lists.mysql.com
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 my real
world problem. Clearly I didn't provide enough detail. Keeping with my
Neves [EMAIL PROTECTED]; mysql@lists.mysql.com
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 my real
world problem. Clearly I didn't provide enough detail. Keeping with my
example, essentially I'm
by a
disinterested third party; ignore it if you like
:-)
Rhino
- Original Message - From: Ian Klassen [EMAIL PROTECTED]
To: Marco Neves [EMAIL PROTECTED]; mysql@lists.mysql.com
Sent: Friday, January 20, 2006 3:49 PM
Subject: Re: Database design help
Marco,
Thanks for your help. I
- From: Ian Klassen [EMAIL PROTECTED]
To: Marco Neves [EMAIL PROTECTED]; mysql@lists.mysql.com
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 my real
world problem. Clearly I didn't provide enough
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
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
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|..|..|..|
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
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
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
26 matches
Mail list logo
