do you mean that the code for each site is the same and is deployed on the same server, but in a different directory on the server?
if you want to go your way, use svn or git to deploy automatically. Every time you submit code, it will automatically Synchronize to every svn or git library you set up.
but if every site code is the same, why not make a site?
this can also solve the following problems:
data is different
each data table adds a customer id, and each piece of data is bound to a customer. For example, customer A wants to check the orders he has received and use his id to check the database, which is his data. The data between customers do not affect each other.
page styles are different
you can make a few more templates so that your customers can set styles in the administrative background, and the banner images they upload can only appear on their home page.
the buyer of the customer is different
the buyer table also adds the customer id.
the logic of a module is different
you can also write different back-end logic according to the customer's id.
concurrency problems
No matter how powerful your server is, there are times when you can't handle it when you have a large volume of business. If you follow your method, migrate part of the client's code to another server. If it is a whole website, you can do load balancing.
< H1 > attribute changes often encountered in e-commerce systems < / H1 >
Database design often changes due to future requirements.
so when designing, you need to change the original column into row data, and when you want to change the column, you can do this by inserting row data.
give me an example.
I have a cell phone.
has name price, flip or slide, smartphone or non-smart phone and other attributes .
< H1 > if you follow the design of the column. < / H1 >
then, the value of each phone is as follows
ID //
11000
2. 4000
3. 2000
if you want to add operating system fields, you need to change the table structure to add fields.
< H1 > adopt row design < / H1 >
property sheet
ID,
1.
2. //
Commodity list
ID,
1 1000
2 4000
3 2000
Commodity attribute
Commodity ID, attribute ID, attribute value
11 Symbian
12 straight
21 ios
22 straight
this way, if you want to add attributes. Just add the data of the property sheet and the data of the commodity property sheet, and there is no need to change the structure
< H2 > functional differences between different customers < / H2 >
first of all, there is only one set of programs and only one database.
- so, the functions that customers need to implement must be implemented by our program. Each function is added to a menu, and the property sheet is used to set
.
- then for customers who need to activate this feature, add a table, refer to the product property table,
function
ID
1
2
...
customer function
customer ID, feature name
1 1
1 2
do a good cache, then when I read customer 1, I will find that customer 1 has advertising function and Wechat function. Then the program displays the added page according to this display page, which can be operated in the background and also displayed in the background
.
A source code for ten customers. If customer A wants to add a function and you update it all to all the code, what will other customers think when they suddenly see this new feature? it's what he wants, why does it suddenly have this feature?
if you can give it to ten clients, it's fair to maintain it ten times.
this, the key is that you should have a core control. If your database and host can handle it, you can consider designing the agent development menu.
this table records the functions that each agent can hold, and after you add a new feature, if the table does not exist, that is, only the agent who adds the function data to the agent menu will own and open it. You can also do the design of its datasheet according to this idea. Of course, this is just a simple idea, which can only be said to provide you with an idea. In addition, that is quite right, ten customers, maintenance ten times is also fair, after all, you have to have 10,000 users, you can not just one person maintenance.
We have a similar function, that is, Wechat's public management platform. Of course, there are not so many people or dozens of people.
Code:
what we designed is the same set of code, the common functions written in the base class, and then the extension functions are implemented by the inheritance class. According to what you said, you probably won't have this problem, because it looks like your functions are exactly the same. Consider using a set of codes
database:
We use the same host mysql, but different database. The reason why database is divided instead of a table here is that it is OK if both tables are distinguished by a unique id, but select and update will consume a lot of resources and may even lead to unexpected situations.
so I think you can also consider this implementation, because you wrote that your host is very powerful, assuming that you can really run 1W merchants, then this should be no problem; Of course, the big guy's plan is also very comprehensive, and these specific things have to be realized according to the actual business
with all due respect, when you can't even figure this out, you don't have to worry about ten thousand merchants using your products.
suggest to redesign the database, adopt object-oriented, deal with multiple people with one code, give different identities to everyone, and let them do different things. In fact, it's the same as giving likes to goods, and collecting is the same.
