Class Design Help: Related Data

[Fuse3k]

Hi All,

So here's a general scenario: I create a VB Class which allows the user to create a client record for a table. Let's assume one of the fields in the Client table is a field called SalespersonID which relates to another table with Salesperson Name and their respective ID (key).

What's best practice for designing a class to append a record to a table which has related data? Do you store both the Salesperson's Name and their respective ID in the the class properties, create a custom type, or something else?

TIA
-Brian

 

[Ranman256]

no, the ID is all you need to relate back to tSalesPersons.
If you use a master/child form, the master record would be the salesperson (and ID)
and the sub form would also have ID ,and subform data.
The ID will fill in automatically.
Use the Form Wizard to make one.

 

[jdraw]

Fuse3k/Brian,

Please tell us a little more about your requirement.
You mention VB, I'm taking that to be VBA.

If you are describing a vba Class module, then Markk posted a sample database here that may provide some insight and ideas.

 

[stopher]

What's best practice for designing a class to append a record to a table which has related data? Do you store both the Salesperson's Name and their respective ID in the the class properties, create a custom type, or something else?

If you are not planning to refer to a saleperson elsewhere in your OOP model then sure you can just have properties in your client class for that sales person. You just need to make sure your accessor methods ensure your salesperson info is consistent e.g. don't simply provide separate methods for changing surname and firstname because then someone using the client class could change one but not the other. Provide a function that requires both as parameters.

Yes you can use a custom class which makes the data and coding a bit more logical e.g, salesperson.name etc. But once you start thinking you are better with a custom type then you might as well go the whole hog and create a class. IMHO if you are into OOP for a penny then you are into it for a pound (an expression worth not quite as much since Brexit). You can deal with all the idiosyncrasies of a salesperson within the salesperson class e.g. validating the email, thus avoiding cluttering your client class. But the killer is once you have created a salesperson class, you can reuse it elsewhere.

For linking OOP with relational databases, jdraw's link is cool if you can get head round it.