As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In this day and age, with a new NoSQL databases popping up every weekend..
Are there any good and up-to-date resources on how to pick a database(s) that will suit your web application needs?
If you're interested in trade-offs and feature comparisons Wikipedia tends to be updated more than others.
Relational Database Comparison: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
NoSQL Feature Comparison: http://en.wikipedia.org/wiki/Comparison_of_structured_storage_software
If you want a more direct answer you can always post the requirements you have and you'll get a lot of helpful answers. It's a pretty broad subject and, other than feature comparison matrices like the ones above, you'll mainly get subjective answers unless you have an objective question (ie specific requirements).
Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison
NoRAM DB => “If It Does Not Fit in RAM, I Will Quietly Die For You”
Although I would also advise considering a SQL data back end ( e.g. PostgreSQL, Drizzle ) with a cache layer, e.g. Redis on top of it. Unless you have an actual reason to use NoSQL. The reason can by the way be NoSQL is cool and I'd like to learn it, but if that is all, usually it may hurt at the end.
Does the problem have to do with money transactions? Are you going to have a distributed system?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm preparing to create a database to store contact and demographic information for tens of millions of people. Given the large dataset and the heavy use it will get I'm trying to determine whether a nosql database would be a good fit for this.
Usage of the database will involve processing records in batches of 10,000 to 1,000,000, checking whether a record already exists in the database, and adding it if it does not (if it does exist in db, I'll want to retrieve the existing UUID). So it would need to be quickly searchable by UUID, name, address and/or phone. In my reading so far, nosql databases appear to allow only a single primary key. However some of the features I've seen described in the documentation aren't real clear to me. Is there a nosql database what would be suitable for this or should I stick with MySQL and focus on improving that? What features should I be focused on in nosql terminology?
MongoDB supports indexing, even multiple indexing.
http://docs.mongodb.org/manual/core/indexes/
As does MySQL. The only feature you should focus on is...well... indexing. Relational vs. non-relational is your choice. Most big companies with huge DBs are using relational, obviously - it's the tried-and-true method.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have experience over Relational DB's but very little over NoSQL data stores and for these two I need a well defined reason to say that one needs to move to NoSQL.
Since I cannot replicate a situation where I can push a DB to its limits and make it lose performance, let alone scaling it. Therefore wondered about to see what others had to say. May be I have been treading the wrong path path, but I have read people saying why we should move to NoSQL or how or even at what sort of different scenarios eventually leads to NoSQL. Article after article explains what Big Data is and how it is managed in the NoSQL domain and how useful it is with it architecture of being scalable, robust, ACID, BASE, Data modelling from Sql to NoSQL, etc features.
But none would provide some solid numbers. E.g. A web service that had a DB of X-TB's and eventually the queries (read/write/etc) took T-seconds or so to complete so we moved on to NoSQL to get back the performance. My concern is at what point it really did a team shift to NoSQL when they said, OK we're done with scaling and everything, lets move on to NoSQL!
So I have had to ask SO users. Maybe someone can share some valuable information. This seems to be an open issue for me as I have been trying to get hold of even just one document that explains a real case scenario where the SQL DB eventually had to be replaced with a NoSQL DB/DS/storage.
Any guidance is much appreciated.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm a java developer, currently starting developing a hospital management system that will server patients, doctors, accountant, .... etc the system is really huge that may have 900,000 records/day, data is really growing so fast, for that i'm confusing in which database to use since i have the following options: (Percona Server(Mysql), Oracle, SQLServer), since the application will run on network with average of 45 online users.
I hope to find a good answers here.
Thanks in advance
If you have been working with MySQL for 6 years then stick with it!
You don't want to add the burden of learning another database as well as having to develop your application.
If you are unsure if MySQL is up to the job then run some tests. Write an app that runs multiple threads inserting 1M rows and see if your servers can handle it.
I'm guessing the brand of the database you choose will be less important than the performance of the platform (machines) it is running on.
There is no good or bad answer to this question. Basically it is as good as the DBA knowns to manage it.
If asking this question it would be wise to group a team of people well known with various systems to find out the best practice. To answer such a case, even more with very sensitive data, it is not just a simple solution which will do the trick. A thorough process of decision making is very important. Not only from a technical but also from a security and business side.
As per as think your database is large you can go with oracle.but the decision also depends on the expertise of people working with you and availability of resources.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why do some frameworks (like CakePHP, Kohana, Zend, Django, less - Rails) create some kind of SQL abstractions instead of a raw SQL database access? E.g. why do we need to make some perversions instead of a usual queries?
UPD: are there any SQL-injection reasons of this purpose?
Basically a good abstraction layer makes it easier for the developer to use a database, and not care what what and which kind of database he is connecting to, thus speeding up the development process.
Check out http://en.wikipedia.org/wiki/Database_abstraction_layer, the most common pros and cons are listed here.
Thats called abstraction. Usually its done to be db specific indipendent.
Sql will be built based on the db type of the connection..
There are two main reasons.
Database Indepence
The code can be applied to different databases. MySQL, MS SQL-SERVER, ORACLE. And with a little wrangling to other DBs using OBDC like MSAccess, or CSV files.
Separation of Database Code with Business Logic
Most frameworks follow this model: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
It's primarily an attempt to reduce what's known as the impedance mismatch between the relational storage of the database and the domain model within your application. Without the ORM you often find yourself writing "left hand right hand" code modelobject.property = reader["field] where you're mapping values from the storage format you've received from the database into your model.
In summary, hopefully the ORM allows you to concentrate on solving the business problems without having to worry about all of the plumbing. We're not there yet but we're getting close.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Interested in some opinions on whether SQL is becoming obsolete. At my place of work, ORMs (in particular, Doctrine) are growing more popular for our web dev projects, and early indications seem to be suggesting that it's capable of doing pretty much everything we need for these small to medium sized apps (haven't yet had any major reporting requirements though). Is this the future of data modelling for web dev projects? (Apologies in advance if this is not the forum for this type of question).
SQL is not obsolete nor is it becoming so. There are plenty of programmatic interfaces that make it less of a requirement to learn it in the early stages of application development, but nothing replaces good knowledge about it.
It is also interesting to note that several NoSQL backends support a subset of SQL as an interface to them. It will be a long time before it goes away.