Rajani,
Sorry for the extended delay in responding. I made two attempts to post while on the road, but problems with the host's server kept it from being posted.
Anyway, I have to agree on the database design issue. In this case, a relational database could be created, but would be overly complicated for what is actually required.
In short, I have a main table that stores a customer ID, a product ID and two registration numbers.
For each product ID, there is a separate Password table that includes two fields, a registration number and the associated password.
At the end of the transaction, one or more of the passwords from the appropriate Password table are given to the user, based on the registration number(s) provided in the main table.
In most applications, I would create a link or relationship between the Registration number fields in the main table and the Password table. However, because the Password table to link to is dictated by the Product ID, the Registration fields would have to be tied to multiple Password tables. I believe this is a Many-To-Many relationship.
To create such a relationship doesn't seem very organized, and to create a clean relational system, while still possible and feasible, would mean creating a whole bunch of other tables that unnecessarily expand the size of the overall database without really adding any benefits.
Then again, as I'm fairly new at all this, I could be all wet.
Again, thanks, and have a great Holiday season.
Best regards,
TSeroogy
|
