AFAIK, only in the sense that there are standards utilized with relational databases that help maintain data consistency, but there are modern nosql alternatives that are perfectly reasonable from a business perspective. Someone with industry/nosql experience might have more thoughts.
In my experience, if you code properly, data consistency is not a problem. Almost all of Amazon's services run on NoSQL databases, and they rarely have issues. I'm not an expert on the subject though, most of my experience is using MySQL.
In my experience, if you code properly, data consistency is not a problem. Almost all of Amazon's services run on NoSQL databases, and they rarely have issues. I'm not an expert on the subject though, most of my experience is using MySQL.
When I first started with NoSQL I had everything wrong. To get them to work properly, you have to store redundant data which is necessarily inconsistent. Let me share the revelation by example, the old blog example.
In a relational database you might have one table like this:
id, pub_date, title, author, blog_text
If you want to display a list of blog posts you do a query like this
select id, title from blog_posts where pub_date <= today
If you want to display one blog post you do a query like this
select * from blog_posts where id = X
So, I tried a couple NoSQL databases and tried to just carry this logic over. I tried to create a document for each blog post, thinking that a document was the same as a row. This did not work because the ability to query is not really the same. Instead, what you really want is to actually have multiple documents with the redundant data, and all that work the database used to do for you now has to be done in your application.
So yes, you might have a document for each blog post that has fields like title, author, blog_text, etc. But if you want to show a list of blog posts, you will not query across those documents. Instead you will have another document or set of documents just for that. Some data will be redundant, such as blog titles, authors, etc.
This is where you get the performance boost. Since you can't join, you don't join. All your queries to the database are ridiculously simple. They are simple because you do all the work at the time you write the data. If someone updates the title of a blog post, you have to update it in multiple documents.
The logic kind of makes sense. Back in the day disk space was scarce. Now, it is the least of your worries. Why NOT write the data to multiple places? The only cost is useless disk space, and it saves big on performance in certain situations. The only problem is that your writes become more complicated, so slightly more work in application development, but it's not really that hard. It's harder to be clever and save space than it is to be redundant and waste it all over the place.
The problem is what if you aren't developing a blog. You are developing accounting software. The NoSQL database isn't ACID compliant, or have any of that other hardcore database stuff. It's not just possible, it is likely, that things will get out of sync. Update the blog title in one document, but not another. Update your account balance in one document, but not another. One of these isn't the end of the world, the other is a huge deal.
Proper relational databases solve a lot of the problems (and indeed were designed to solve said problems) that end up being re-solved by people who don't understand them and use other inappropriate solutions for certain applications.
3D reconstruction of Vesta (blue points) and the trajectory recovery of the DAWN spacecraft that orbited it. I reconstructed it from only camera images
Read Scott's post and came to roughly the same conclusion as Rym. From what I know of my old neighbour who codes software for finance, efficiency is far less important than consistency.
Banta nothing against you for selecting the image but AN M4 IS NOT A GODDAMN MACHINE GUN
According to U.S. law it is.
US law decides how things should be classified domestically. In military contexts, no one classifies it as such.
In Military paperwork no-one classifies it as such. Unless being specific is important (identification, distinguishing it from other firearms, etc) they'll be called either by name, or whatever comes to mind, from gun, to rifle, to machine gun, to weapon, to "that fuckin' thing" and so on.
Then again, I suggest you don't take that seriously, since as the joke goes, if the paperwork doesn't say it, then reality is obviously wrong.
I think that even before US gun laws got quite so "labored over" for lack of a better description, it was considered pretty common usage to call almost any gun that looked like a rifle and fired multiple times per trigger pull a "machine gun".
We all did it as kids in the 80s and we certainly didn't have any deep understanding of the politics of United States gun control. We used to bring our toy guns to school to use on the playground.
In Military paperwork no-one classifies it as such. Unless being specific is important (identification, distinguishing it from other firearms, etc) they'll be called either by name, or whatever comes to mind, from gun, to rifle, to machine gun, to weapon, to "that fuckin' thing" and so on.
Then again, I suggest you don't take that seriously, since as the joke goes, if the paperwork doesn't say it, then reality is obviously wrong.
I didn't mean to support Jack's odd criticism, which is why I said "classify" instead of something like "refer." I know that in crisis, people say whatever words they can find.
To be fair, if the guy hasn't gotten a good look into the room then yeah I could see how he might think it is a machine gun. But I still consider an M4 to be an assault rifle. Anyway, yeah it is silly.
My friend was just making that poster in compsci and I looked over and told him there was an actual lost animal poster downstairs. Got him to print it off and let me put it up.
Comments
can someone confirm/deny?
BEGIN;
do your shit
COMMIT;
It's not hard.
In a relational database you might have one table like this:
id, pub_date, title, author, blog_text
If you want to display a list of blog posts you do a query like this
select id, title from blog_posts where pub_date <= today
If you want to display one blog post you do a query like this
select * from blog_posts where id = X
So, I tried a couple NoSQL databases and tried to just carry this logic over. I tried to create a document for each blog post, thinking that a document was the same as a row. This did not work because the ability to query is not really the same. Instead, what you really want is to actually have multiple documents with the redundant data, and all that work the database used to do for you now has to be done in your application.
So yes, you might have a document for each blog post that has fields like title, author, blog_text, etc. But if you want to show a list of blog posts, you will not query across those documents. Instead you will have another document or set of documents just for that. Some data will be redundant, such as blog titles, authors, etc.
This is where you get the performance boost. Since you can't join, you don't join. All your queries to the database are ridiculously simple. They are simple because you do all the work at the time you write the data. If someone updates the title of a blog post, you have to update it in multiple documents.
The logic kind of makes sense. Back in the day disk space was scarce. Now, it is the least of your worries. Why NOT write the data to multiple places? The only cost is useless disk space, and it saves big on performance in certain situations. The only problem is that your writes become more complicated, so slightly more work in application development, but it's not really that hard. It's harder to be clever and save space than it is to be redundant and waste it all over the place.
The problem is what if you aren't developing a blog. You are developing accounting software. The NoSQL database isn't ACID compliant, or have any of that other hardcore database stuff. It's not just possible, it is likely, that things will get out of sync. Update the blog title in one document, but not another. Update your account balance in one document, but not another. One of these isn't the end of the world, the other is a huge deal.
3D reconstruction of Vesta (blue points) and the trajectory recovery of the DAWN spacecraft that orbited it. I reconstructed it from only camera images
Then again, I suggest you don't take that seriously, since as the joke goes, if the paperwork doesn't say it, then reality is obviously wrong.
We all did it as kids in the 80s and we certainly didn't have any deep understanding of the politics of United States gun control. We used to bring our toy guns to school to use on the playground.
http://boardgamegeek.com/boardgame/854/doge
I'm glad someone else did the Photoshop work for me. They did a much better job than I could have.
And a few panels later:
(Fun facts, it's also from the same manga (if not the same chapter) as Sail's current cyclopian avatar.)