Hi
If you're searching for, effectively, %123% you probably can't use IN(). You
could get away with wildcard patterns - if it's a heavily used field
consider an index to increase performance. Hard to tell if this may be a FK
of sorts, but if so you should use it as one which may involve normalisin
On Thu, 2008-07-24 at 09:34 +0530, Sivasakthi wrote:
> How can we normalize the tables? could you explain bit more?
>
>
> Thanks,
> Siva
>
>
Normalization is a complex subject. I suggest you search the web for
tutorials. Try the search terms: RDBM normalization
--
Just my 0.0002 milli
How about: WHERE ( field1 LIKE '123,%' OR field1 LIKE '*,123,%' OR
field1 LIKE '%,123' OR field1 = '123' )
Note that this could that a long time on large tables. You'd be better
off to normalize your tables ;)
How can we normalize the tables? could you explain bit more?
Thanks,
Siva
On Wed, 2008-07-23 at 17:05 +0300, Ali Deniz EREN wrote:
> Hi all,
>
> I have a problem as below:
>
> A text field -Lets call it 'field1'- contains datas seperated by
> commas(,) like this (123,5764,8795,9364,11,232,. and go on) And so
> my lines like these:
>
> id title filed1
> -
>A text field -Lets call it 'field1'- contains datas seperated by
commas(,)
> like this (123,5764,8795,9364,11,232,.
The solution is to normalise the data.
PB
Ali Deniz EREN wrote:
Hi all,
I have a problem as below:
A text field -Lets call it 'field1'- contains datas seperated by
comma
Jay, thx for your speedy reply.
MySQL does indeed know the "WHERE IN" syntax (bad coding on my part).
I have another question.
There are two tables in the db from which I want to gather information.
These tables are identical, except for two fields that have different
names, the same types (but ot
[snip]
ANSI SQL has the WHERE key IN (value1, value2, ...)
MySQL doesn't seem to support this.
Is this a faulty assumption, or am i stuck with WHERE key = value1 OR
key = value2 ...
[/snip]
It is a faulty assumption, see
http://dev.mysql.com/doc/mysql/en/comparison-operators.html
SELECT stuff F
Hi Jim,
It's probably the time taken to parse the query with so many IN ()
values than it is to actually look them up. You can get an idea of how
long it takes to parse the query by comparing the time with 1 IN value
vs. thousands without the IN values actually matching any rows (e.g.
dummy values
On Thu, 30 Oct 2003 15:48:05 -0700, Knepley, Jim <[EMAIL PROTECTED]> wrote:
Is it anyone elses experience that queries with large IN stanzas in a
WHERE clause don't scale very well?
It seems like it's beyond a linear performance hit when I have a large
number (thousands) of tokens in an IN clause,
My mistake. I failed to mention that there are two tables, bar and baz.
And, I found the answer to my question. Thanks everybody.
On 12/2/02 5:52 PM, "Adolfo Bello" <[EMAIL PROTECTED]> wrote:
> Isn't this sort of impossible?
> You are asking for something like "a set which contains as an elemen
Isn't this sort of impossible?
You are asking for something like "a set which contains as an element
the set itself"
WHERE fooId IN (fooId)
Adolfo
> -Original Message-
> From: Peter Abilla [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 02, 2002 1:43 PM
> To: [EMAIL PROTECTE
Hi.
This is mentioned in the fine manual:
http://www.mysql.com/doc/e/x/example-Maximum-column-group-row.html
Bye,
Benjamin.
On Fri, Aug 31, 2001 at 01:46:43PM +0200, [EMAIL PROTECTED] wrote:
[...]
> Normally I would go about like this:
> SELECT currency_rate.currency_id, currency_dat
I think you will you have to do it in 2 steps using a temporary table. This
is one of MySQL's biggest weak points.
..chris
- Original Message -
From: "Mattias Jiderhamn" <[EMAIL PROTECTED]>
I have a table
CREATE TABLE currency_rate (
currency_id VARCHAR(3),
currency_date DA
13 matches
Mail list logo
