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 5 years ago.
Improve this question
Our development database now has 263 tables. During development we only work with a few. Is there anyway to organize all the tables into something like folders?
There is no way to organize tables hierarchically that is meaningful to MySQL.
As others have noted, you can maintain separate schemas (in MySQL, databases), or you can develop and use a table naming structure that organizes your tables in a way that is meaningful to users (but is still not meaningful to MySQL).
The only thing that occurs to me is to use different databases for different sets of tables. See CREATE DATABASE
I don't believe there is a way to organize tables other than to move them into other dbs. What you could do is prefix the ones you use frequently so they are always at the top (this only works though if you have defined constants for your table names for just such an occasion so you don't have to trudge through your source code changing every instance it is called).
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 6 years ago.
Improve this question
So, imagine the situation, when we have such data: one part of it is better to store in RDBMS, and another one in some of NoSQL (Mongo, f.e.). Is it correct to use 2 separate DB? Or should I find a some compromise for data structure to use only one?
I guess, when we use 2 DB we need much more resources (and carry more about fault tolerance), but we can have better stucture. Or my way of thinking is totally wrong? Never heard about this kind of practice, so want to ask more experienced people.
Btw, sorry if my english is bad.
Using different dbms for different kind of data and purposes in the same application is definitely legit. It does come to some cost as you mentioned, but if the benefits outweigh the costs I would go for it.
A not so uncommon usecase would be to have a rdbms as persistent datastorage and add Lucene as fulltext search engine. So you can use the rdbms for your acid compliant operations, to enforce constraints.
In the next moment you can use lucene to search for some words, get the corresponding identifier and then ask the rdbms for more information belonging to the identifier.
If you check the 'more exotic' NoSQL databases (graph databases, column based databases) you propably will find more such usecases in which 2 dbms are great to supplement each other.
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 8 years ago.
Improve this question
Is the basic technique behind querying across logical shards just querying them all at the same time and consolidating the results?
There doesn't seem to be any built-in features of MySQL or Postgres that allows you to query across logical shards, so I assume you must query each shard or get some sort of software to sit in front of that database that indexes or queries for you.
MySQL is working on a new technology called MySQL Fabric to do this. It's still in early development (as of this writing). But they apparently intend it to be a built-in feature in MySQL 5.7.
You can also use Shard-Query today. This acts as a proxy to query across all your shards transparently. That is, you can write simple SQL queries as if you didn't have a sharded architecture. Shard-Query rewrites SQL and runs queries against each shard in parallel, then combines the results.
I don't know what, if any, solutions exist for PostgreSQL to automatically query across shards.
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 9 years ago.
Improve this question
Is it possible/reasonable to have a voting system on NoSQL database ?
For example how would be possible to store StackOverflow question into the NoSQL database.
I can easily imagine almost everything except how the relation will work between question/vote/user. Everything else can be stored in one document, like tags, comments(assuming there are relatively small amount of comments on posts, in my case I will not have comments anyway), user information, etc... but can't imagine how to store user votes as document will become huge. One of the options is that I can have votes stored in separate collection/document, but it will mean that while loading a question there will be a need to send another request to check if the user have voted for a question or not.
A good reference is the MongoDB documentation on Embedded documents vs Referenced documents, since those are what you seem to be referring into your question. There's no perfect solution, as both have their trade offs. You just have to make the best decision based on the type of operations/queries and their frequencies that you're expecting to be run on your database.
Honestly, until your database starts getting some serious traffic, the difference between SQL and NoSQL won't matter. Pre optimization can end up doing more harm than good, so I would just go with the one that is easiest to get deployed and you're more comfortable with to begin with.
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 am in the middle of attempting to help my company digitize their history. One project is taking maintenance records for equipment and putting them into a mysql database. The idea is to be able to pull up a history at any time without flipping through piles and piles of paper.
My experience is limited to using phpMyAdmin to create tables and fumbling through php to output data how I want it. I've never used a relational setup.
The data fields would always be the same, the database would be populated via copy/paste from Excel (until such time comma delimited importing can be figured out), and this data would not need to be edited by endusers. It is strictly for viewing/printing purposes only.
Example fields:
id, unit number, unit_type, date, maintenance_performed
My question is, would putting all this into one table be an acceptable way to accomplish this task? Or would a relational setup be better due to the different types of units? Why?
I would focus on getting the data into the database and not on its storage. You are going to have enough problems copy-and-pasting the data in. For instance, how will you ensure that the dates are always in a consistent format?
After the data is loaded into tables, then you can worry about how to optimize it for querying purposes. How will new records continue to be uploaded? That will be a very important part of the process (I would recommend having field a creation date in the database, in addition to other information in the record).
After the data is loaded, you can worry about the best structure for organizing it. This is analogous to a real archivist, who tends to start by gathering lots and lots of data, and then figuring out the best way to organize it.
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 8 years ago.
Improve this question
I created a table view and joined it to an existing view. Is this a good way?
I'm wondering when the rows in the table piles up, will the performance be affected?
What are the other possible problems that I will encounter when I do this?
It is hard to say whether this way is good or not. It depends on your database design. Views have some advantages, so if you need to use views, then use them. But views may have bad performance, have a look at this article - MySQL VIEW as performance troublemaker.