Hmm. If we're talking pure DB theory, then the whole point is to apply
the DRY principle as much as possible. At the point you have multiple
copies of the same data, unless your programmers are perfect (and they
aren't, I promise), you *will* have stale data. Better to have only one
place to
Hi Kevin,
Well the basic information, company description and personalized
options will be selected many times (whenever a user submits a query).
It will basically be show on the result page of the search engine.
The user's login / password well is used to login, then the user may
update the comp
te:
> From: Alex K <[EMAIL PROTECTED]>
> Subject: basic style shema question
> To: mysql@lists.mysql.com
> Date: Friday, January 18, 2008, 11:14 PM
> Hi Guys,
>
> Let's suppose I have the following table:
>
> create table companies
> (
> id
At 11:44a -0500 on 18 Jan 2008, Alex K wrote:
To summarize one table vs. many tables with one to one relations?
As per usual, it depends on your needs. For most flexibility, and to
give the DB the best chance to give the best plan for the possible
requests I might make in the future, I gener
te:
> From: Alex K <[EMAIL PROTECTED]>
> Subject: basic style shema question
> To: mysql@lists.mysql.com
> Date: Friday, January 18, 2008, 11:14 PM
> Hi Guys,
>
> Let's suppose I have the following table:
>
> create table companies
> (
> id
Hi Guys,
Let's suppose I have the following table:
create table companies
(
id int(11) not null auto_increment primary key,
# user's login and password
email varchar(100),
passwordvarchar(100),
# basic information
company_namevarchar(10
