Hello.
On Sun 2003-01-12 at 11:18:08 +0000, [EMAIL PROTECTED] wrote:
>
> I've setup a mysql table field which is a SET type, but it seems to be
> completely pointless. I can't see why I should use a SET type rather than a
> string for the following reasons:
>
> 1. I appear to be able to store whatever I want in there. MySQL doesn't
> enforce the rule that what I stick in there must be items from the set I
> defined when I defined my field.
Correct. In general MySQL doesn't enforce field types for any value.
But if you choose a completely invalid value, MySQL will store an
marker (here: empty string) instead, e.g. it's similar for the date
type. The reasoning for this behaviour is mainly speed.
But you oversee an important (depending on use case) fact: SETs are
saved as bit-fields, and therefore use much less disk space than the
equivalent as string.
> 2. What I do a SELECT statement the only way I can interrogate records to
> determine if a certain set value is present is to do a WHERE MySet LIKE
> '%MySetMember%' which is fairly useless if set items contain other set
> items in their name (ie if I have set items "A","AB","ABC" then obviously
> my LIKE query searching for an "A" will have issues).
>
> Or am I missing something?
Yes. The function FIND_IN_SET(). It solves the problems you describe
and additionally is a lot faster for the SET type because it uses bit
fields instead of strings comparisons.
HTH,
Benjamin.
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
