Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I’m searching for a method to build a development architecture. Only i dont know the best pratices.
Note: i'm working with the symfony framework
Imagine you have multiple website, must all of these websites have their own database and cms. But when you need to change a column in the DB, you’ve to change it to all DBS. Or is it beter to have one central DB, where you could save data based on company_id.
And what to do with code reusability. For example i’ve created a new feature for website 1, how could i make this feature reachable for all my other sites without updating all websites separately.
I hoop you co-developers could help me out with above questions.
The approach of having separate DB for each separate site has two major benefits: resilience and flexibility.
If one of your projects gets compromised and someone is able to corrupt the database, that same person would not be able to bring down your entire infrastructure. And a developer making a minor fuckup in an UPDATE query can't affect the other sites either.
When one of your sites manages to grow unexpectedly, with separate databases it is extremely simple to migrate it to a different hardware.
As for the updates in structure, those SQL changes should be documented anyway, so each of your project should have some migration scripts for doing it. Those scripts then can be executed by the automated deployment code.
As for code re-usability .. well ... you should separate those reusable fragments in their own libraries, put then in your private repositories and then just connect them using composer's configuration. That way you can roll out the changes both incrementally and all at once.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a server with few websites there and its something like in the following picture.
I decided to add some more panel as a new website. Each website had its own structure but I did remove the unnecessary part so I'm just using one single database for all of the websites. Recently I had an issue with high CPU usage of MySQL. I'm not sure if it is because of using one single database or not.
In addition: Is there a way to get data with cronjob less than one minute? I tried sleep() but I guess its not a good idea.
Sharing one database amongst multiple applications has some serious disadvantages:
The more applications use the same database, the more likely it is that you hit performance bottlenecks and that you can't easily scale the load as desired.
Maintenance and development costs can increase: Development is harder if an application needs to use database structures that aren't suited for the task at hand but have to be used as they are already present. It's also likely that adjustments of one application will have side effects on other applications ("why is there such an unecessary trigger??!"/"We don't need that data anymore!"). It's already hard with one database for a single application, when the developers don't/can't know all the use-cases.
Administration becomes harder: Which object belongs to which application? Chaos rising. Where do I have to look for my data? Which user is allowed to interact with which objects? What can I grant whom?
Coming back to your issue on high resource usage, this is ideally caused by multiple applications utilizing the same database which increases needed CPU utilization. I strongly suggest maintaining every application with its own database for increased performance and scaling capabilities.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am planning to create a php myadmin inventory system for a large firm (at least 1000 branches)
There will be a centralized server and database kept in one place. where all the branches can insert and retrieve data from the centralized server. there will be at least 2000 sales bill and 100 purchase bills (at least 1 gb data from a branch)
My doubt is that is it technical feasible for me to use php and mysql (apache) for this project? the data will be vast? do i need to change the front end to jsp and back end to any other database?
I dont know much about php and mysql database....? any one who went through this scenario already could help me.
I suspect this question will not stay open for long, it is way too generic, but for what its worth: yes, it is feasible, I did a similar project before.
You would have to be careful with your data schema structure, and
would need to tune mysql server quite a bit, but this is true for
any database.
You also might want to employ local servers and replication to
central server.
Your reporting server should be separate, since its workload
should not affect main data performance.
These are some thoughts that come to mind.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to start a project, technically based on the code of another project -- a clone. E.g. a forum or an online shop, whatever. I'll buy the code base. But then it's theoretical possible, that the developer/seller is able to manipulate something remote, e.g. export the customer database or just change/delete files with code and make the code useless, if he wants to.
What strategies (maybe best practices) are there to defend oneself in such cases?
The only viable option is a code review by a person competent in detecting such security flaws. This is by no means a cheap process, nor will there be any guarantee of success.
Even teams of people writing and reviewing code designed to be secure often fail to fill every possible security hole, eventually some hacker finds these holes and exploits them. Take for example the heartbleed bug in OpenSSL.
Regardless of it being the developer who has malicious intent or it being a hacker attacking his otherwise good code the same approaches apply. To prevent your customer DB being downloaded put it on a separate layer with it's own security. If the DB server will only provide the web app with one customer at a time and not provide a list then downloading th whole db is very hard.
Hackers do manage to change and delete code on servers. To mitigate this a tripwire system should be used to detect these changes, then the code can be restored from a simple backup.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to create web application in php, using symfony.
It's sort of a community creator. But my question is, should I make only one database for all the application, or should I create a database every time a user creates a "community". What are the best practices, in relation to this. Thanks for all your responses.
Creating a new database every time a user creates a new community is a bad idea in my opinion, for more than a few reasons. I'll give you the most important ones:
It's very unsafe. It means that the overall database user that is connecting to the database server has a higher level of privileges (beyond the standard CRUD operations). That is considered bad security practice, as a security flaw in your application could open the databases for all kinds of attacks.
It's hard to maintain. I'm not sure how many communities you expect to get, but imagine that an update of the code requires you to update a given table in all of those databases.
For each database another connection is used, which means that another socket connection is in use. When using persistent connections, this means a lot of database connections may be open at the same time (depending on the scale of the application). This could cause bottlenecks and thus performance issues.
The first and second reasons are by far the most important.
If, however, you feel the need to separate each community from another in some way, I suggest using tables with a prefix for every community. In that case the first reason is migitated somewhat, as the database user only has to have rights to a single database, and the third reason is no longer in order.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
One of the first things I noticed while installing Wordpress MS and creating my network was that 9 db tables are created for each new site. Obviously this means that if I had, for example, 10,000 users, I would end up with 90,000+ database tables. Since this could obviously be avoided (I think) by instead modifying the existing Wordpress database schema, why was the system designed this way? For compatability, ease of use, etc.? Because they don't expect to be able to support that many sites? I am trying to figure out if I should proceed with the system as-is or start hacking to make the db schema scale well. Should I be worried about potentially ending up with so many tables?
Yes, the code can support thousands of sites, and many users per site. Hardware will be the limiting factor.
To answer your other question of why was it done this way? It keeps the WordPress code base from having to be altered a LOT from when it was created. It is one of the important reasons that plugin authors and theme authors use $wpdb->prefix instead of assuming wp_ for table names.