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.
One of the disadvantages people point to with using foreign keys in a relational database is the overhead of making sure the parent table exists before doing any insert operation. (Example). As your database and operation grows, this effect is amplified. Does anyone know if large sites on the web use them then? If so, how do they get around that extra overhead? If not, as your development team gets bigger, it seems that that could cause a lot of potential bugs/conflicts/miscommunication/orphan-rows.
Any insight?
I work for a telecom, yes they do, often the cost of FK is too small compared to severity one major incidents (hours of time lost investigating, patching ...) that can be caused by accidents due to lack of FK checking.
This depends on your definition of "large site": If for example Citigroup online bank is a "large site", I guess they do.
What I mean by this example is, that the use (or not use) of foreign keys, access by stored-procedures-only etc, depends on the requirements of the business logic (and maybe its legal framework) more than on technicalities only.
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.
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?
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.