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.
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 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.
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 9 years ago.
Improve this question
I would like to set up an online store and a point of sale application for a food coop.
My preference is php/mysql, but I can't find any projects which accomplish both these requirements. I was wondering if it would be possible to use separate store and pos apps and get them using the same product database.
The questions I have about this are:
is it a bad idea?
Should one of the apps be modified to use the same tables as the other or should there be a database replication process which maps the fields together (is this a common thing?)
is it a bad idea?
The greatest danger might be that if someone successfully attacks your online store, then the pos systems might get affected as well. E.g. from a DOS attack. That wouldn't keep me from taking this route, though.
Should one of the apps be modified to use the same tables as the other or should there be a database replication process which maps the fields together (is this a common thing?)
If you can get at least one of the two systems to use the products data in read only mode, then I'd set up a number of views to translate between the different schemata without physically duplicating any data.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am developing a php application using CodeIgniter. I am planning to split the single MySQL database to multiple sqlite databases. That is, one database(MySQL/PostgreSQL/SQLite) that handles authentication and one sqlite database per user that holds information related to users. I do not use any joins and it will have more reads than writes.
Is it a good idea to split the database into multiple sqlite databases for speed? Also, will it have problem when scaling to multiple servers? I can use redirection depending on user to point to right server.
Edit:
Decided to use MariaDB as my server for all users.
By splitting data into multiple sqlite databases, instead of speed, you will gain major headache and time sink. Don't do this, unless you know you have to, and can prove it with hard numbers, not hypothetical scenarios.
The advice above applies if the system you're building has some value (will be used commercially, etc.). Of course, if this is just a toy/training project, you're welcome to do whatever you like, and learn from it.