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
What is the mysql database best practices for multiple users?
When build a SAAS cloud projects are you best to have a new database for all users or put a users data in their own table or just put it all in the same database and use primary key to find a users data?
What are the pro's and con's?
I NEVER create per-used tables. If the logical meaning of the data is the same, then they should share a table. I also never allow automatic creation of tables - creation of tables is done by a DBA, by hand (sometimes by running a program or a script, but always initiated by a human being.
I also have a hard-and-fast rule to have static SQL (using bound parameters for values only). This lets me keep tight control of what is read from/written to the database, and where - very important to avoid SQL injection.
Related
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 2 years ago.
Improve this question
I am little new to PHP, MySQL and web development. I have seen MySQL Views are "Virtual Tables" and can be used to represent data table virtually. And my problems are,
Are there any performance increment when we use MySQL Views in a PHP 7 MySQL application?
Are there any security increment?
Can we use MySQL Views for JSON REST API requests?
As far as I know. The view is like you save a query to a database. So you can save time to write a complex query.
I think yes. Because you can grant users access to view rather than directly to the table.
To get the data is yes, but a function like edit and delete I don't think so.
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 4 years ago.
Improve this question
I wanna build a web app which will store a lot of data for each user, so I've got a question, which solution is better:
create a separate database for each user
create one big database and in every table add a column with user id
?another option?
Thanks!
There is no question that creating a "big" table with a column for the user id is the way to go. SQL is optimizes to handle data in tables, not to handle zillions of tables.
Here are some reasons why:
Performance. Having a separate table for each user means that you will have lots of empty space on data pages.
Combining data across all users. Having separate tables means that your queries will be really complicated.
Maintenance. Having separate tables means that adding indexes, new columns, and so on is a nightmare.
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
What I want to do is caching every database query into files. The queries will be cached with names including users' user names or user ids. Of course when a user changes its information, the cache file will be replaced with the new one. Even the interactons like friendship between users will be cached.
If I have 1.000.000 users, I will have millios (maybe billions) of files. Is this good or bad for the performance?
This will fill out your file system so it depends on the amount of space you have. Also, this would degrade performance based on the file lookups if you have a large number of active users.
In any case I would recommend using Memcache or APC as the laravel docs say.
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 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 have a small question about performance during dev (web especially) :
Is it better to :
perform operations directly on the DB and retreive a "ready" result
OR
retreive the data from the DB and then do the operations?
Mat is right (see comments): there is no general answer to that. It depends on the structure of your data, on the queries you want to run and on your database system.
Nevertheless I would say, in most traditional cases it is better to join, filter, group, cumulate and sort your data directly in the DB - just because your DB is built to perform exactly this kind of tasks. If your data structure and indexes are built up right, it will be hard to write code beating the database in terms of performance on this actions.
Indeed, there are complex queries where it is better to split it up and do some work in your code. But unless you have more than 10 tables involved or big sub queries, you should not think about this to much.