Francisco,
> I think I understand your point, however it would be very laborious after
> you do all development to find out you need to de-normalize.
Not terribly. Views and Rules are good for this.
> On your experience at which point it would actually help to do this
> de-normalization in Pos
On Fri, 1 Aug 2003, Josh Berkus wrote:
> My attitude toward these normalization vs. performance issues is consistenly
> the same: First, verify that you have a problem. That is, build the
> database with everything in one table (or with child tables for Nullable
> fields, as above) and try to r
Ron,
> You snipped out too much, because that's exactly what I said...
> Another way of writing it: only split the table if some of the fields
> are not unitary to the entity.
Sorry! No offense meant.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of bro
On Fri, 2003-08-01 at 12:44, Josh Berkus wrote:
> Francisco,
>
> > Yes all fields belong to the same entity. I used 100 as an example it may
> > be something like 60 to 80 fields (there are two tables in question). I
> > don't formally do 3rd normal form, but for the most part I do most of
> > the
Francisco,
> Yes all fields belong to the same entity. I used 100 as an example it may
> be something like 60 to 80 fields (there are two tables in question). I
> don't formally do 3rd normal form, but for the most part I do most of
> the general concepts of normalization.
>
> > If not, then good
On Fri, 2003-08-01 at 12:14, Francisco J Reyes wrote:
> On Fri, 1 Aug 2003, Ron Johnson wrote:
>
> > Do all 100 fields *really* all refer to the same *one* entity,
> > with no repeating values, etc?
>
> Yes all fields belong to the same entity. I used 100 as an example it may
> be something like
On Fri, 1 Aug 2003, Ron Johnson wrote:
> Do all 100 fields *really* all refer to the same *one* entity,
> with no repeating values, etc?
Yes all fields belong to the same entity. I used 100 as an example it may
be something like 60 to 80 fields (there are two tables in question). I
don't formally
On Fri, 2003-08-01 at 11:08, Francisco Reyes wrote:
> If a table which will be heavily used has numerous fields, yet only a
> handfull of them will be used heavily, would it make sense performance wise to split
> it?
>
> Example
> Table 1
> Field 1
>
> Field 100
>
> Table 2
> References Fie
If a table which will be heavily used has numerous fields, yet only a
handfull of them will be used heavily, would it make sense performance wise to split
it?
Example
Table 1
Field 1
Field 100
Table 2
References Field 1 of table1
.
Table n
References Field 1 of table 1
So table 1 basi
