Hello Lightingale,
Lightingale wrote:
Hi there,
I am new to using mysql. I want to prepare an application for my employer. The
application will be accessed by staff from as many as 10 different departments
such as sales, marketing, admin, finance etc. The users will be using DML
commands on t
Hi,
I am new to using mysql. I want to prepare an application for my employer.
The
application will be accessed by staff from as many as 10 different
departments
such as sales, marketing, admin, finance etc. The users will be using DML
commands
on the tables. My question has two parts:
Part
Hi there,
I am new to using mysql. I want to prepare an application for my employer. The
application will be accessed by staff from as many as 10 different departments
such as sales, marketing, admin, finance etc. The users will be using DML
commands on the tables. My question has two parts:
Pa
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
I have two tables, Applications and Settings. Here are the two schemas:
mysql> desc Applications;
+-+-+--+-+-++
| Field | Type| Null | Key | Default |
Extra |
+-+
At 15:53 +1000 on 06/07/2004, Ligaya Turmelle wrote about Re: Advice
on Database Schema Design:
I think I get what you are trying to do and it sounds good (though I am
still a beginner). The only thing I can think that might cause a problem is
since you have more then a couple of tables you MAY
I think I get what you are trying to do and it sounds good (though I am
still a beginner). The only thing I can think that might cause a problem is
since you have more then a couple of tables you MAY have to write joins for
all of them . Only you would know if you can do that and/or be comfortabl
I am converting a form that was originally designed to be Email
Submitted into a Submit-to-PHP-Page Form (which will then insert the
data into a MySQL Database).
I expect no problems in actually scanning the submission to extract
the data but I have some questions on the design of the Tables t
16 matches
Mail list logo
