How to structure a PHP project for multi ecommerces working with the same crm

Asked

Viewed 42 times

-5

I need to develop 5 virtual stores in different lodgings, where all will be managed by a hosting x.

H2,H3,H4,H5,H6 -> (H1) In the H1 hosting will be the CRM panel, where will be printed orders, registration of products and etc.

All hosting will work with the same database, where you will have the settings of each store, when registering a product or editing it will be possible to determine in which stores it will be available.

So far all right, the problem is in the images of the products, the best option would be to display the images pointing to H1 or manually upload each product in dirty respective hosting?

On the idea of the project structure in working on different accommodation, it is a good idea?

php mysql
  • 1

    More information is needed to help: are these stores all managed by the same team (users)? When you say "hosting" you are talking about a single system or server installation, or URL addresses ? Will you develop the system or is it a market CRM/E-commerce? If it’s you, you have the database model, how did you resolve the relationships of the data of each store with your products? The image I believe is a consequence of all these previous decisions being defined and modeled.

  • Right. I’m developing the stores for my own use. I have a plan Lojagospel.com.br Lojagamers.com.br Lojacountry.com.br Lojagamers.com.br Lojacountry.com.br Lojagospel.com.br Lojagamers.com.br Lojacountry.com.Lojafitness.com.br These stores will be managed for min in crm.lojaMain.., I created a table for stores where the store id and its settings are located, in the products table has the store field (varchar255) where in each store a search is done through a like=store in each store

1 answer

-1


According to your answer to my question, I will then answer the specific question

the best option would be to display the images pointing to H1 or manually upload each product in dirty respective hosting?

If the products are unique per store, I mean, it won’t sell the same product in every store, the ideal is to associate the store id as a foreign key in the product. As for going up the images per store, if the entire base of the stores is unique to them, then upload them in the same place, since the logic of your application will identify the product and load the correct image from the disk.

However, I believe you have some major problems modeling your database when you speak

in the products table have the store field (varchar255) where in each store is made a search through a like=store in each store

It seems to me that you don’t understand how the relationship between tables of a relational database is done, using primary or foreign keys.

I advise studying about MER (Entity Relationship Model).

Complementing my answer with an explanation of why to avoid varchar for primary and foreign keys: if your store id is numerical, the ideal is to work with numeric fields, type fields that accept characters for this purpose are less performatic. If we speak exclusively of the varchar type, it has the problem of not being indexable in most database managers, then its application will have a lot of performance degradation, especially in Join moments of queries' relationships.

  • Some products will be available in more than one store, I will explain better to work all the stores in the same bank: some products will be on order, ex: pink flower T-shirt, (it will be taken from a stock of flat T-shirts ) where in other stores tbm will have Prod that will be taken out of the stock of single prints-free buns. the goal is that all administration, order printing, inventory control is done in a single location, without having to go into each store to manage, all orders came out with production instructions from the main store and distributed by respective store.

  • Okay, as to whether it’s worth a single system basis for this context, yes it is. To solve multiple relationships use an intermediate table, for example: product -> product loja_product <- store ... where product store contains the store and product id, so you have a relationship n to n covered. The stock if it is global, can be a field in product. But I keep my answer above, I think it really necessary that you study Database Modeling to get the solution right

  • All right, I’ll do a little research right now.

  • I again understood that as I am working with type N:The ideal is to create a table as you said to link the products table to the right store table? Working with a varchar field on the product and using loja1id, loja2id, etc... has what disadvantage? I just wish I knew out of curiosity.

  • If your store id is numerical, the ideal is to work with numeric fields, type fields that accept characters for this purpose are less performatic. If we speak exclusively of the varchar type, it has the problem of not being indexable in most database managers, then its application will have a lot of performance degradation, especially in Join moments of queries' relationships

Browser other questions tagged php mysql

You are not signed in. Login or sign up in order to post.