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:
The real design problem is that I'm new to this. However, ...
I'm putting together my own knowledgebase using MySQL and built from
various sources including books and list groups of similar form to this
one. It's basically an expanded bibliography.
Different form would have different data
Frank,
Friday, February 01, 2002, 2:29:37 PM, you wrote:
FJS The real design problem is that I'm new to this. However, ...
FJS I'm putting together my own knowledgebase using MySQL and built from
FJS various sources including books and list groups of similar form to this
FJS one. It's
Hi.
This was accidently sent to me privately.
Bye,
Benjamin.
- Forwarded message from Gianstefano Monni [EMAIL PROTECTED] -
From: Gianstefano Monni [EMAIL PROTECTED]
To: Benjamin Pflugmann [EMAIL PROTECTED]
Subject: DB programming - design question
Date: Thu, 4 Oct 2001
I have a perl-DBI-MySQL database app. that handles everything from my
order entry to my accounts payable. I am in the process of cleaning up
a lot of the code I've written to make it easier to maintain. I
probably use the following DBI staement handle about fifty different
places on
I have a perl-DBI-MySQL database app. that handles everything from my
order entry to my accounts payable. I am in the process of cleaning up
a lot of the code I've written to make it easier to maintain. I
probably use the following DBI staement handle about fifty different
places on
Andrew Ward writes:
The only way I can see of dealing with this is to create tables like
ID,QUESTION,RESPONSE
1,YEAR,2001
1,SEX,1
1,AGE,3
1,RATING A, 7
1,RATING B, 6
...
This doesn't strike me as very smart. I would greatly value anyone's
Andrew Ward wrote:
As I said, not all organisations were asked the same questions so I can't
just put the data in directly
The only way I can see of dealing with this is to create tables like
ID,QUESTION,RESPONSE
1,YEAR,2001
1,SEX,1
This doesn't strike me as very
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 all!
I have a question for all of you... I would very much appreciate your
input.
I'm building a database for a radio station. The database must allow
the DJ to enter what they play and when, and allow the program director
to create weekly reports for the record labels.
I'm wrestling
I'm building a database for a radio station. The database must allow
the DJ to enter what they play and when, and allow the program director
to create weekly reports for the record labels.
[snip]
First, to maintain a single table with every bit of track data there is
(ie, title, artist,
-of theoretical db design question
I'm building a database for a radio station. The database must allow
the DJ to enter what they play and when, and allow the program
director
to create weekly reports for the record labels.
[snip]
First, to maintain a single table with every bit of track data
The rule of normaliztation is (usually) if you have data repeated in a table,
you need another table. So here's how *I* would do it.
A table for each: DJ's, Albums, Artists, Genres (a category table of sorts),
and Tracks. You might even want a table for record companies, so that's not
Ben Bleything wrote:
Hello all!
I have a question for all of you... I would very much appreciate your
input.
I'm building a database for a radio station. The database must allow
the DJ to enter what they play and when, and allow the program director
to create weekly reports for the
On 28-Jul-2001 Ben Bleything wrote:
Hello all!
I have a question for all of you... I would very much appreciate your
input.
I'm building a database for a radio station. The database must allow
the DJ to enter what they play and when, and allow the program director
to create weekly
When you are designing a database and you are thinking about creating a
comma delimted list, this is a good sign that you need to rethink your
design. Bitfields are a good option, however if you ever need to add
elements to the bitfield (ie bitfield A can signify the presence of 4
elements, but
So you're saying like this...?
Albums
--
ID,Artist,Title,Label
Tracks
--
Title,Length,TrackNumber,AlbumID
Where there is one album table and one track table, and each
track references back to the album that it is a member of?
I'm liking that... It doesn't make it easy
This looks like an order-lineitem situation, which I would imagine would
look like this:
ORDERS
ORDER_ID
CUSTOMER_ID
ORDER_DATE
LINEITEM
ORDER_ID
PRODUCT_ID
LINEITEM_QUANTITY
At 02:00 PM 6/18/2001 -0500, you wrote:
I have a design problem I was hoping some of you could help me out
with. I
]]
Sent: Monday, June 18, 2001 3:00 PM
To: [EMAIL PROTECTED]
Subject: Design question
I have a design problem I was hoping some of you could help me out with. I
am writing a shopping
cart system (as if there wasn't enough already) and I have one problem that
has me stumped.
A person can order more
share good stuffs with everybody.
From: Jeff Jones [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Design question
Date: Mon, 18 Jun 2001 14:00:29 -0500
I have a design problem I was hoping some of you could help me out with. I
am writing a shopping
cart system (as if there wasn't enough
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
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
One approach might be to use a hierarchal menu -- first level
is first letter of the company, second level is all of the
companies whose names begin with that letter.
Or, set a search to pull up the list of companies which contain
a certain phrase.
-Tilghman
--
"There cannot be a crisis
101 - 126 of 126 matches
Mail list logo