Hi,
Split frequently used columns from other non frequently used. Splitting them
will improve the disk access. You don't need to separate as too many tables.
You need to index all the tables if you split into many.
Saravanan
--- On Fri, 1/18/08, Alex K [EMAIL PROTECTED] wrote:
From: Alex K
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
Hi,
Split frequently used columns from other non frequently used. Splitting them
will improve the disk access. You don't need to separate as too many tables.
You need to index all the tables if you split into many.
Saravanan
--- On Fri, 1/18/08, Alex K [EMAIL PROTECTED] wrote:
From: Alex
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
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
