If ur storing "ALPHANUMERIC" values, then use varchar instead of TEXT
On 7/11/08, Waynn Lue <[EMAIL PROTECTED]> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 4:20 AM, Ananda Kumar <[EMAIL PROTECTED]> wrote:
>
>> Yes, i definitly agree on the third table if "APPLICATION FUNCTIONALITY"
>> increase and need
On Mon, Jul 7, 2008 at 4:20 AM, Ananda Kumar <[EMAIL PROTECTED]> wrote:
> Yes, i definitly agree on the third table if "APPLICATION FUNCTIONALITY"
> increase and need to add more columns into the current tables.
>
> On 7/7/08, metastable <[EMAIL PROTECTED]> wrote:
>>
>> Ananda Kumar wrote:
>>
>>>
Yes, i definitly agree on the third table if "APPLICATION FUNCTIONALITY"
increase and need to add more columns into the current tables.
On 7/7/08, metastable <[EMAIL PROTECTED]> wrote:
>
> Ananda Kumar wrote:
>
>> I feel creating the third table would just be duplicating the data and
>> occupying
Ananda Kumar wrote:
I feel creating the third table would just be duplicating the data and
occupying space. Creating index on existing table and quering would be
better. But you got a good point of FOREIGN KEY CONSTRAINT. Can we use this
constraint on current "SETTINGS" table, rather than creatin
I feel creating the third table would just be duplicating the data and
occupying space. Creating index on existing table and quering would be
better. But you got a good point of FOREIGN KEY CONSTRAINT. Can we use this
constraint on current "SETTINGS" table, rather than creating the third
table.
On
Waynn Lue wrote:
I have two tables, Applications and Settings. Here are the two schemas:
mysql> desc Applications;
+-+-+--+-+-++
| Field | Type| Null | Key | Default |
Extra |
+---
how many rows would be there in this table and what is the growth rate of
this table.
regards
anandkl
On 7/7/08, Waynn Lue <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jul 7, 2008 at 2:49 AM, Ananda Kumar <[EMAIL PROTECTED]> wrote:
>
>> >>Problem is that there are combinations that I'll never care ab
On Mon, Jul 7, 2008 at 2:49 AM, Ananda Kumar <[EMAIL PROTECTED]> wrote:
> >>Problem is that there are combinations that I'll never care about
>
> What do u mean by the above statement.
>
What I meant is that I will never do a query for (e.g.) (30, ).
So I have an index on values that I'll potenti
>>Problem is that there are combinations that I'll never care about
What do u mean by the above statement.
I would definitly go for the first solution, though ur taking more time on
the index, but u dont need to keep adding columns and doing joins as u think
would happen in the second approch.
K
