hopkinsc wrote:Do they effect anything within the application if i were to leave them alone? how many of these would be ok to leave alone or should i make sure that there are none within my application?
It depends on what you want to get and how you want to get that. Although a thorough coverage on impact of synthetic tables vs. manually performed association can be found here (thanks to John Witherspoon), basically a synthetic table is the way QlikView solves linkage between two or more same named fields.
Say you have an invoice header table and an invoice line table. You can create a composite key using field "Document Number/Year" in both tables (header and lines) or you can leave it to QlikView, which will create a synthetic table with all possible combinations between Document Number and Year.
If your source is reliable, both will work, and you will be able to find any invoice and its lines selecting only the Document Number in both cases.
Sometimes, though, you don't want it that way, because it doesn't corresponds to your actual datamodel. In the example above, say you have the field "Customer ID" in both header and lines. You'll likely not going to need both, and you may not load one of them since they are not useful for your analyses in QlikView. Anyway, a synth table will be created, since QlikView will find "Document Number" and "Customer ID" twice in your datamodel. In this case, you will not load the "Customer ID" field for one of both, so the next time you reload you won't have that synth table.
If they are done on purpose, they will work, and are useful. If they are created as a result of an unwanted / unknown linkage between two tables, this may affect your performance and results, not because the synth table itself rather than having some fields that should not be there.
Anyway, take a look at John's post for further information and testing with synthetic keys.
Regards.
.png "Miguel_Angel_Baeyens"){kind=avatar}
