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
As .NET developers currently we're using RavenDb as our default choice of database, in the nosql scenario. Now that Microsoft introduced DocumentDb, a nosql document database-as-a-service, we're looking for the differences between the two. Database-as-a-service does seems nice, as we run RavenDb on our own server.
Ayende Rahien as an interesting post, but it's a little outdated as it compares with an old DocumentDb version. Nevertheless it's still a good read.
Edit: After reading Thoughts on Azure DocumentDB I started doubting about the pricing of DocumentDb. Let's say my data model consists of 7 collections, this means I would have to pay 7 * $25 = $175 per month! I must be making some kind of mistake here, right!?
Edit2: The idea of the creators of DocumentDb seems to put more than one type of document into a single collection, which seems a bit odd to me after using ravendb for a while now. The term collection caused some trouble understanding DocumentDb pricing as it is something completely different in DocumentDb then in RavenDb
In which scenario would you choose DocumentDb over RavenDb?
The post recommends that you put a lot more stuff in a single collection than you would otherwise. I'm not sure of the wisdom of that long term, but they propose it as a way to keep costs down. Also, since there is no cross-collection transactional isolation, it might be better if you need to update more than one document at a time, to keep them in the same collection anyway.
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 3 years ago.
Improve this question
I'm working on a side project of mine using rails api. The app is like a project manager which the structure is gonna be different based on the company type. For example a company which is doing production is different with a company that provides services. Does it make sense to use multi db in this case so based on the company type the users are gonna have different interface and structures?
Thanks for your time in advance
It makes sense to use multiple databases when you're reaching the resource limits of a single database in your application. Of course this presumes you have also followed best practices along the way (efficient queries, effective caching strategies, etc.) Rails 6 has support for replicas which allow you to automatically separate your db writes from your db reads based on the HTTP verb. Beyond replicas, Rails 6 supports using a distinct database with its own replica for a custom collection of ActiveRecord models.
For more details I would recommend taking a look at the Rails Guides on Multiple Databases.
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
SQL is one of the most powerful and most currently used languages​​, but for purposes of curiosity and learning would test new technologies and want to know what are the fastest.
I text talking about NoSQL (json) and also about "plain text" file (. Txt or. Dat or. INI) with information from publications, settings, and the like.
What is the fastest processing, taking for example the Wordpress CMS is a very famous and one of the largest in the world, it uses SQL, say we make a request of 50 posts from the database, using the default template, all standardized compared with a requisition 50 posts from the same hierarchy but in file. txt or json file, which technology and fashion that renders faster?
If you will work with storage only in read or write, json or text file will be more faster than mysql, otherwise if you want to process complex data, mysql is faster.
If you want to work with less overhead, try to use SQLite database or similar
NoSQL databases like Redis, MongoDB is faster than MySql, but for using it, you must have personal hosting with root access
Although I don't have numbers to prove my guess, I think that any database will always be faster than a text file, just consider its indexing capabilities.
If instead you want to compare different databases, then, as others already said, it's a matter of the specific domain / problem you're working on and the structure you gave to the specific database schema.
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
There is a lot of articles on the web supporting the trend to move to a graph database like Neo4j... but I can't find much against them.
When would a graph database not be the best solution?
Any links to articles that compare graphs, nosql, and relational databases would be great.
Currently I would not use Neo4j in a high volume write situation. The writes are still limited to a single machine, so you're restricted to a single machine's throughput, until they figure out some way of sharding (which is, by the way, in the works). In high volume write situations, you would probably look at some other store like Cassandra or MongoDB, and sacrifice other benefits a graph database gives you.
Another thing I would not currently use Neo4j for is full-text search, although it does have some built-in facility (as it uses Lucene for indexing under the hood), it is limited in scope and difficult to use from the latest Cypher. I understand that this is going to be improving rapidly in the next couple of releases, and look forward to that. Something like ElasticSearch or Solr would do a better job for FTS-related things.
Contrary to popular belief, tabular data is often well-fitted to the graph, unless you really have very denormalized data, like log records.
The good news is you can take advantage of many of these things together, picking the best tool for the job, and implement a polyglot persistence solution to answer your questions the best way possible.
Also, I would not use neo4j for serving and storing binary data. There are much better options for images, videos and large text documents out there - use them either as indexes with Neo4j, or just reference them.
When would a graph database not be the best solution?
When you work in a conservative company.
Insert some well thought-out technical reason here.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So, I just started a new job a few weeks back. It is my first job doing software, and I have been tasked with learning how a giant project works. Now, the guy before me left NO (zilch) documentation or comments anywhere in the source code. In addition, he applied basically EVERY design pattern in the famous design patterns book by Gamma, etc...
My question is, how do I start? I have tried setting break points for certain calls that I want to learn (learn bit by bit), but because of the 5 million design patterns employed, every call goes up about 7 levels just to finish, and by then, it's hard to keep track of the 20 some objects being created and used.
Has anyone had a similar experience? A few pointers on different methods to try?
Specs: language - VB.net
IDE - Visual Studio 2010
Using - Windows Forms
Brain - Melting
Inheriting a large project without documentation is always a huge pain in the ass. I hope you have already accustomed your manager to the inconvenient truth that it will take several weeks or even months until you can maintain that project efficiently.
I would start with creating some UML class diagrams. That could tell you a lot about how the system works and which design patterns are used where.
While doing so, I would also add comments to the code with everything I learned about it. When I am not sure if I understood what the code does correctly, I would add a common string like "NOT_SURE" to the comment. Later, when I have a better understanding of the system, I could use a text search to find and revise these comments.
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
I know the basics of mySQL and database normalization.
I am getting into Microsoft programming now and plan to do a large website using ASP.NET MVC. The level of complexity of the website is probably similar to StackOverflow and other database-intensive websites. Except mine won't expect so many visitors of course :)
I hear Entities is the way of the future and ASP.NET MVC tutorials seem to use entities a lot instead of linq to SQL. Also I read Entities are likely to support other databases which would be useful for me later on.
I was thinking of learning to use Entities and wondered if the Microsoft DB stack requires that you first learn SQL, and then ADO.NET, and then Entities... or if a single book on Entities should cover my needs? What would you tell a motivated person to study, given that I don't want to read 6 months of learning material before coding. I want to get started soon but I don't want to misuse a database in a risky manner (security wise).
If Entities are overkill or too complicated, I could also study ADO.NET or whatever is a bit higher level than just inlining SQL queries in my code. I'm open to suggestions that work with MVC!
Well, learning good stuff never hurts but if you want to get started and you want to use SQL Server as your DB, go with LINQ to SQL. LINQ to Entities is more complicated than LINQ to SQL and is designed to make the database tier transparent. It's more useful when you need your application to work seamlessly on plenty of DB engines.
By the way, before you ask, "no, LINQ to SQL is not dead."
I'd suggest that you'd probably be best focusing on LINQ-to-???, where ??? could be Entities, nHibernate, or SQL. I don't think it would be particularly useful to go back and look at DataTables, DataReader, etc. You'll need to be aware of how things work under the hood with Connections, Transactions, etc., but any reasonable treatment of the LINQ-to-??? stuff should cover enough of this to get you started. If you run into issues where knowing the underlying implementations using lower-level constructs is required, you can always dig in then.