Dave,
Rather than maintaining a third table you could create a view. It's
always there, it's always current, there is no database "bloat" from
redundant data, and you don't need to worry about integrity. As the
data becomes outdated, you can move it to another DB. Less IS
more <g>.
Ben Petersen
On 18 Jun 2001, at 11:48, David Ebert wrote:
> We have service information that needs to support different numeric
> requirements at data entry (i.e., maximum number of units), but whose
> numeric formats are not incompatible.
>
> I've designed three tables: one for entry of face-to-face service units,
> another for days of shelter (including partial days), and a third into which
> the other two are inserted after a quality assurance review.
>
> I intend to insert the rows from both of the entry tables into the master
> service table then remove the rows from the entry tables: sort of like a
> posting routine. Given that I have not used a PK/FK scheme between the
> entry and master tables.
>
> If, for whatever reason, an insertion should fail I'd not want to remove the
> entry records. How can I verify that all records were inserted, or do I
> need to be worried about it at all? I don't intend to require uniqueness
> below the entry-table level and will have an autonumbered integer as a PK in
> the master service table.
>
> tia
>
> Dave Ebert
> Huckleberry House, Inc.
>
>
