Subject | Re: Triggers to automagically add/modify/delete data in another table ? |
---|---|
Author | Adam |
Post date | 2006-05-10T00:20:33Z |
--- In firebird-support@yahoogroups.com, Adriano <fadrianoc@...> wrote:
table and using nulls. It is often the reverse. It is concerned with
the efficiency of data storage and the consistency of the data.
As soon as you duplicate the values of Field1 and Field3, you
introduce the risk that these fields become out of sync. Are you
familiar with using foreign keys and defining SQL joins, because to me
anyway it appears to be simply what you are after?
Adam
>database) one
> Adam, Alan,
>
> >If TableB contains some other fields, then I can understand the
> >structure. If however there are no other fields aside from the
> >FIELDID in tableB, then I don't know what is achieved by creating the
> >table in the first place.
>
> >Normalisation 101: Duplicated data is often a sign that the database
> >structure needs to be normalised.
>
> In effect is tableA that contains more data (columns).
> TableB contains the same data of TableA but not ALL the data.
> As said and simplifing the structure (that obviously is more complex):
>
> TableA
> FieldID FieldA FieldB FieldC
>
> TableB
> FieldID FieldA(the same of tableA) FieldC(the same of tableA)
> It does not contains FieldB
>
> At this point It would be correct to create (for normalisation
> only table and leave blank FieldB when not necessary (for thecontability
> movement of tableB that do not need it) ?Normalisation is not simply about putting everything in the single
>
> Thank you very much for your help
table and using nulls. It is often the reverse. It is concerned with
the efficiency of data storage and the consistency of the data.
As soon as you duplicate the values of Field1 and Field3, you
introduce the risk that these fields become out of sync. Are you
familiar with using foreign keys and defining SQL joins, because to me
anyway it appears to be simply what you are after?
Adam