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 using an email service API (can use either JSON or PHP) to send emails, and I want to store the replies into either MySQL or Mongo.
What do you think would be better for large amounts of email message storage, MySQL or Mongo?
It sort of depends on what you are doing, and what kind of metadata you want to store.
I have used both, but I have recently preferred to use MongoDB just because the way you store data (document-centric) is more conducive to the type of applications I work with than relational databases.
If what you want to store is a list of emails, and the replies to that email, then MongoDB might be a good way to go, since you could create a document structure like this:
{
'sender':'me#me.com,
'subject':'Hello world!',
'to':['tom#me.com','dick#me.com','harry#me.com'],
'body':'Hello, World, and stuff.',
'replies':[
{
'from':'tom#me.com',
'subject':'re: Hello World!',
'body':'Please stop sending me SPAM'
},
{ ... next reply...}
]
}
This makes it very nice to be able to query for specific messages and responses. Now, if you need to be able to query by individual users, the email addresses used, etc, and your primary use-case is going to be random queries from different directions, then MySQL might be better, since MongoDB doesn't really have support for joins.
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 4 years ago.
Improve this question
I'm building an application with the instant messaging functionality.
The application will allow the users to send files/images as well as normal text messages.
I decided to take the approach with storing the files on the filesystem and write only the file paths to the database. There will be no updates to the files (only insertions and deletions).
Which database would be the best for storing a large amount of file paths, that would be easy to query for a certain user files?
I would go with MongoDB. My experience is that a document based approach using a single Messages collection would be best. Each message document then contains all of the file paths. This eliminates joins and better supports potential future functional requirements changes.
MongoDB also provides great ways to deal with old messages such as TTL indexes.
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 CSV File's With Different Columns With Few Common Columns, We Are Currently Using Excel To Remove Unwanted Rows Clean The Data, and Generate Reports, I Am Thinking Of Using Elasticsearch As A Solution For Data Storage, Transformation, Load And Reporting.
Is Elasticsearch A Good Choice For This Use Case ?
Elastic Search is, as the name indicated, using to quick search. It is build upon Lucene and similar to another Apache project, Solr...
If you want to query the raw data or do some simple aggregation upon it. It is fine and you can also use Kibana to come up with some fancy GUI so your audience can interact with the data and you can even come up with some dashboard to demonstrate some basic staff. However, it is not a replacement of a data base.
If you want to update or join.. you had better use some data base ... sql + mongo or hive for big 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 am thinking of storing persons contact data centrally. So there will be so many persons and each will have their contact list. There will be more number of updates and selects on database as user will be searching their contacts or searching for a person not in his/her contact list. Person may be updating their contact details. But inserts in database will be limited because only one time enrollment will be there. I am confused in using databases MySQL or Neo4j. Because when I think of searching person from database neo4j seems better. But when I think of handling millions of records MySQL seems better. So can anyone suggest which database suits best? MySQL/Neo4j/ both MySQL and Neo4j or some other database?
Neo4j allows you to store the connections between the people via their contacts, so if you want to leverage the network effect in your application it makes sense to look into that.
It all depends on how you want people to search and interact with your app. If treat people as individual records with no connections then MySQL is good enough. Otherwise Neo4j would probably work better.
IF you have the time to a tiny PoC with some realistic data with both and then decide for yourself.
you can use MySQL latest version it is quite simple and relevant to your need , you need to just use locking system on your database or you can lock your table when inserting or updating.
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 have a project which is using NodeJS and I have different entities for example, people and places.
I need the ability to find both types of entities by location together so what I was thinking of doing is having an index on a field called, type, for example, which would be either person or place and make use geospatial indexes, does this sound a good way to do this or is there a better way?
I will probably need a lot of joins too, so should I use MySQL alongside MongoDB and use MongoDB just for delivering the location based queries?
Thanks
This question is a poor fit for stackoverflow, but here's some radom bullet points:
PostgreSQL supports both joins and geospatial. I'd pick that first personally lacking other details warranting a different data store.
A totally valid option would be to keep people and places separate and query multiple collections as necessary. However, if you need to sort the results, then yes best to throw them in the same collection.
You could also keep people and places in separate mongodb collections but have a mapreduce job translate them into a locations collection for search purposes.
Generally, there are lots of ways to do this and the best one depends very much on the specific aspects of you application. Reads vs writes, data stability, data size, query load, etc, etc.
My broad word of advice is start with the most logical, easiest-to-follow, straightforward data organization (separate collections), and deviate from that when you understand the specific pain you have and how doing something more complicated or unusual will be an overall win.
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 trying to write a webapp, where one of the functionality is to exchange messages. I am trying to understand how to store these messages. I do not want to store it in DB. If i have to store in file, then how do i separate between messages.
Any links to some document would be greatly appreciated. I tried googling a lot but could not get hold of any reference
You should think about storing the messages in XML format, and use your webapp to load and parse those XML files into the message objects. Why do you not want to store the messages in the database? There are serious drawbacks to storing in the file system rather then the database (or even system memory).
A file system is a database, just not a relational database.
It's often faster than a relation database, but it has significantly less flexibility for indexing on multiple fields.
Parsing XML is gonna suck whether the XML comes from a database or a file.
Instead, you should do page caching to the file system of HTML, or HTML fragments.