In article <[EMAIL PROTECTED]>,
sheeri kritzer <[EMAIL PROTECTED]> writes:
> On 11/28/05, Martijn Tonies <[EMAIL PROTECTED]> wrote:
>>
>> > Part of me agrees with you, on a "Pure SQL level". but then why would
>> > anyone ever use ENUM or SET?
>>
>> I wouldn't :-)
>>
>> IMO, they're abomination
> > > Part of me agrees with you, on a "Pure SQL level". but then why would
> > > anyone ever use ENUM or SET?
> >
> > I wouldn't :-)
> >
> > IMO, they're abominations that are to be avoided.
>
> Again, part of me agrees with you. But part of me, particularly the
> part that says "our queries need
On 11/28/05, Martijn Tonies <[EMAIL PROTECTED]> wrote:
>
> > Part of me agrees with you, on a "Pure SQL level". but then why would
> > anyone ever use ENUM or SET?
>
> I wouldn't :-)
>
> IMO, they're abominations that are to be avoided.
Again, part of me agrees with you. But part of me, particula
> Part of me agrees with you, on a "Pure SQL level". but then why would
> anyone ever use ENUM or SET?
I wouldn't :-)
IMO, they're abominations that are to be avoided.
Now, ENUM could be a bit useful. The Pure SQL way to avoid those
would simply be a column of the right datatype and a CHECK c
Part of me agrees with you, on a "Pure SQL level". but then why would
anyone ever use ENUM or SET?
-Sheeri
On 11/28/05, Martijn Tonies <[EMAIL PROTECTED]> wrote:
>
>
>
> > I did answer my own question, and that's why I said:
> >
> > > That being said, the point of this post is to ask -- Is MySQL
> I did answer my own question, and that's why I said:
>
> > That being said, the point of this post is to ask -- Is MySQL working
> > on allowing the SET limit to increase? Or is that just too much
> > storage and math?
>
> Using a SET is, I believe, MUCH faster than making a special table
> s
I did answer my own question, and that's why I said:
> That being said, the point of this post is to ask -- Is MySQL working
> on allowing the SET limit to increase? Or is that just too much
> storage and math?
Using a SET is, I believe, MUCH faster than making a special table
simply to normaliz
You, yourself, explain why your suggestion would be a bad fit for this
project: SET is limited to just 64 discrete values per table.
I cannot remember reading that increasing the size of the SET features as
a priority on any development list. I might have missed something but I
don't think tha
On this note, I feel as though the best way to do this in MySQL is to
use the ENUM or SET types, instead of indexing against a separate
table -- I'm guessing SET, so each piece of clipart can be associated
with more than one category. Of course, that eliminates relevancy
searches (which you could
Hi Robb,
Your table setup is correct. In the third table the two ID fields together
form the Primary Key. This makes sure that you cannot add the same keyword
twice to the same image. If you use MySQL Administrator to create your
tables then you just add both columns to the primary key index.
Prog
On Fri, 25 Nov 2005 10:44:44 -0800, Johan wrote:
>> Option One
>> Related tables. Table one (clipart pieces) contains ClipartID and
>> ClipartName fields. Table two (keywords) contains KeywordID, ClipartID and
>> Keyword fields. This option will create an incredibly large related table
>> (keyword
On Friday 25 November 2005 01:44 pm, Johan wrote:
> > Option One
> > Related tables. Table one (clipart pieces) contains ClipartID and
> > ClipartName fields. Table two (keywords) contains KeywordID, ClipartID
> > and Keyword fields. This option will create an incredibly large related
> > table (ke
> Option One
> Related tables. Table one (clipart pieces) contains ClipartID and
> ClipartName fields. Table two (keywords) contains KeywordID, ClipartID and
> Keyword fields. This option will create an incredibly large related table
> (keywords) with each piece of clipart having tens of related fi
- Original Message -
From: "Robb Kerr" <[EMAIL PROTECTED]>
To:
Sent: Friday, November 25, 2005 11:59 AM
Subject: Seeking Opinions
I'm building a new clipart site. I need to have keyword searching. I'm
seeking opinions about table design. Here are my proposed options. If
anyone has a
Robb Kerr <[EMAIL PROTECTED]> wrote on 11/25/2005 11:59:48 AM:
> I'm building a new clipart site. I need to have keyword searching. I'm
> seeking opinions about table design. Here are my proposed options. If
> anyone has any other suggestions, please make them.
>
> Option One
> Related tables. Ta
15 matches
Mail list logo
