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 7 years ago.
Improve this question
Apologies in advance if this is a stupid question. I've more or less just started learning how to use SQL.
I'm making a website, the website stores main accounts, each having many sub-accounts associated with them. Each sub-account has a few thousand records in various tables associated with it.
My question is to do with the conventional usage of databases. Is it better to use a database per main account with everything associated with it stored in the same place, store everything in one database, or an amalgamation of both?
Some insight would be much appreciated.
Will you need to access more than one of these databases at the same time? If so put them all in one. You will not like the amount of effort and cost 'joining' them back together to do a query. On top of that, every database you have needs to be managed, and should you need to transfer data between them that can get painful as well.
Segregating data by database is a last resort.
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 11 days ago.
Improve this question
Program A is good at collecting data while Program B, in another language, is good at creating REST APIs. Is it possible to connect these two with a single database that A and B will read and write to? Performance for database operations is not really an issue in my case.
Sure this is possible. Databases typically can handle multiple connections from different programs/clients. A database does not really care which language the tool that is making the connection is written in.
Short edit:
Also most databases support "transactions". Which are used to cover that different connected clients do not break consistency of your application data while reading and writing in parallel.
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 started to learn mySQL and a thought came to mind, I always see memes about databases and dropping tables, and how much of a problem such an even event can cause. My question is why would someone working in a software development environment ever decide to drop a table or even an entire scheme for that matter?
There can be various reasons, the main ones that come to mind:
As part of a roll back, you migrated something to the production environment which had bugs or shouldn't have been deployed yet. In order to get back to the previous state you'd need to drop the new table.
As part of clean up: legacy parts of the database which you no longer need, old table partitions with already archived data, user schemas of people no longer working for the company.
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 5 years ago.
Improve this question
I am about to develop a small cms\forum. Multiple customers are going to have there own access where the customers can communicate white them.
What is best practices- to make separate SQL db to each customer's cms data or one big to contain all the customers data?
As I cannot comment, so I can only type here.
It is strange that you would like to have separate database for each customer and it seems impossible to manage multiple db for just one purpose or function. For example, how could you identify which db belong to which customer? Also, do you expect to have many resource to allocate to each customer? a db simply waste if the customer is not active.
So, I suggest you to use one db to manage all the customers data which is normal solution.
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 7 years ago.
Improve this question
Optimization was never one of my expertise. I have users table. every user has many followers. So now I'm wondering if I should use a counter column in case that some user has a million followers. So instead of counting a whole table of relations, shouldn't I use a counter?
I'm working with SQL database.
Update 1
Right now I'm only writing the way I should build my site. I haven't write the code yet. I don't know if I'll have slow performance, that's why I'm asking you.
You should certainly not introduce a counter right away. The counter is redundant data and it will complicate everything. You will have to master the additional complexity and it'll slow down the development process.
Better start with a normalized model and see how it works. If you really run into performance problems, solve it then then.
Remember: premature optimization is the root of all evils.
It's generally a good practice to avoid duplication of data, such as summarizing one data point in another data's table.
It depends on what this is for. If this is for reporting, speed is usually not an issue and you can use a join.
If it has to do with the application and you're running into performance issues with join or computed column, you may want to consider summary table generated on a schedule.
If you're not seeing a performance issue, leave it alone.
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 gave a list of tables from our schema in a text file to my boss asking him that we need NOT back up all these tables. Now he is asking me to write a query to return the rest of the tables which REQUIRE BACK UP.
He gave me the hint that I will have to use USER_TABS and DIFF in my query.
Can anybody please help?
I am using ORACLE database.
What criteria defines a table that is "unused" and what criteria defines a table that "needs backup"? And what do you mean by "backup"?
If you're talking about backups, you'd normally be talking about physical backups in which case you back up the entire database (either a full backup or an incremental backup depending on how you've structured your backup strategy). You would not and could not include or exclude tables from a physical backup. You could potentially move the tables to a read-only tablespace which lets Oracle know that they don't need to be backed up again. But it doesn't sound like that's what you're after.