Access product catalogue website style

[MajP]

Not a question of "Will this work" or "How to handle changes", but "How much time do I need to invest and will it produce enough benefit to justify the effort".

That is kind of what I am getting at as well.
With suppliers you can track what categories, or subcategories, or activities. But that is a lot of data to enter and maintain and what will you get for that.
The same thought on associating activites to subcategories and then assigning to products. You can but, can you do all the tagging and then maintain the associations.

 

[Faoineag]

Good morning everyone, I apologise for my silence, I was away for a few days and could not deal with the problem for which I asked for your help. I will now take up your comments

 

[Faoineag]

@MajP @Mark_
I have carefully studied the screenshots posted by MajP with the changes to the tables and it seems so complicated that I think I would almost be quicker to build the whole db from scratch. The question you ask, Mark, makes a lot of sense, if I think about MajP's warning about the fact that maintaining my old set-up could lead to big problems, then I answer ‘yes, it's worth it’, also because I will still have to insert many articles, so the db will grow again and with it the risk of everything crashing because of the errors that are at the base, but at this moment when I have to insert many of these articles on the new website to think of spending so much time on the db structure is not very sensible. In your experience, if you leave the db unchanged, the moment I have about 10,000 products, is the risk that everything will ‘crash’ very high? If that is indeed the case, then I propose again the possibility that one of you, for a fee, build me the correct structure (tables and modules) and I gradually adapt the data

Translated with DeepL.com (free version)

 

[MajP]

I think about MajP's warning about the fact that maintaining my old set-up could lead to big problems, then I answer ‘yes, it's worth it’, also because I will still have to insert many articles, so the db will grow again and with it the risk of everything crashing because of the errors that are at the base,

For the most part I did not quite say that. More I was saying that saving both the Category and Subcategory keys is redundant and you could get out of synch. If you do a good job at enforcing the data integrity at the form level you probably would be ok.

Again. If I select a subcategory Volley Ball net in my data table, I should not have to pick a the related category and save that in my data table. I know through the relation of Categories to Sub Categories that a Volleyball Net is in Sports Equipment. If you choose to store both keys in your data table it will work, but there is a slight possibly you could end up with these keys out of synch. You could have a key for Health Care and a key for Volleyball Net.

I can give you what I think, but still uncertain how you want to handle Activities. I think by creating the Many to Many will be hard to maintain. The big difference was that you want several one to many and did not have that
Supplier can make many products
Products can have many subcategories / activities.

IF you want to send me the real data, I will see if I can get it into the proposed tables and a few forms to see if it makes sense to you.
I will send you a google drive in a PM if you want to upload what you have.

 

[MajP]

If that is indeed the case, then I propose again the possibility that one of you, for a fee, build me the correct structure (tables and modules) and I gradually adapt the data

Did I not already do it for free in Post #60???