Click here to Skip to main content
15,890,282 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
There is an MS Access database which i'm planning to use to store my inventory data. I am trying to built an vb.net App and I'm confused about where to specify table relation as there are some relation between Product-Category-SubCategory so and so..

As I can see there are two ways to do it, First one is to do it in MS Access itself and the other is within the Dataset in Visual studio. Problem is that i don't know which would be a sensible choice as I am new to vb.net.

Can somebody give me an advice on this matter.?

What I have tried:

I have tried setting up on both places and seems like working, But still not sure if it is the right method.
Posted
Updated 29-Oct-18 0:13am
v2

My general advice is to set the relationships in the database and use a View of that relationship to be exposed to any client program.

CREATE VIEW-Anweisung (Microsoft Access SQL) | Microsoft Docs[^]

This design gives you the freedom to change your database later on (ideally, you would just have to adjust the View if you want to do a design change) without always having to change any code.

More likely than not, you will end up having to care for some relationships in your client code but don't do this on an 1 NF level because that will be counter productive since your client code will ahve to change any time you change something in your database.
 
Share this answer
 
If you mean Foreign Key relationships, then the best place is in the DB, because then it can enforce Referential Integrity - a fancy way of saying "make sure the dtaa is all valid"

When you establish a Foreign Key relationship between two tables, the database will enforce Referential Integrity for you:
Invoices
ID, Date, Customer, Total

InvoiceLines
ID, InvoiceID as Foreign Key to Invoices.ID, Product, Quantity, PricePerItem
So you have many InvoiceLines per Invoice, which you would expect.
The DB will prevent you adding an InvoiceLine row unless the InvoiceID has a matching row in the Invoices Table, and will prevent you deleting a row in the Invoices table while any row exists in the InvoiceLines table that refers to it: Referential Integrity is assured.

You can do that in your code, yes - but there is always a chance that you miss something one day, and when that happens it becomes a real PITA to fix your data because you end up with floating data that you no long know what it is related to.
 
Share this answer
 
Comments
OriginalGriff 29-Oct-18 6:48am    
That's pretty much what "... then the best place is in the DB ..." means! :laugh:
Member 14000611 29-Oct-18 7:06am    
Thanks ; )
OriginalGriff 29-Oct-18 7:10am    
:P to you too! :laugh:

You're welcome!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900