Turns out, yes and no. We're distributed already, so it would have entailed setting up another DB anyway, and all the management infrastructure around that. AWS also seemed like a good fit for things that were essentially document-oriented and it seemed that it would be efficient for this kind of data model.

I can answer why WE decided to in this case: Cost and flexibility. For our application, there is a traditional PostgreSQL DB for things that ACID does well. For places we didn't think we'd need that level of transaction we decided that it wasn't cost effective to manage another DB instance, and instead move it to SimpleDB. Scalability wasn't the major driver at the moment, as we're already a distributed system.

FTA:
"In the meantime, DBAs should not be worried, because any company that has the resources to hire a DBA is likely has decision makers who understand business reality."

Bad English aside, I just don't agree. Money != Reality. I have worked both sides of this coin - Startups with plenty of money but don't see the value in proper maintainance of the data store (one almost was put out of business by a disk failure), and very smart startups that are running lean but do understand the risks.

That said, on the deeper level, why does business reality == SQL? Sure I can scale Oracle to support massive DB's (and have), but I could probably get more value from using Amazon's SimpleDB for things that don't require massive scaling. Use the right tool for the job - Hammers are for nails, etc. Do the design work up front, decide how its gonna work, and the right tool should present itself.

We're using both - about five days from our "go-live", and things look good. We just use what makes sense for each part of our application.
For us, this means PostreSQL for the parts that must be transactional ACID, and Amazon's S3 and SimpleDB for parts that don't. In practice, for the 1.0 release, this means things like notes, user accounting, and documents are in S3 and SDB. The rest is plain ole SQL.

Not that there wasn't a learning curve with our developers - we're a bunch of old-time enterprise type developers, so "letting go" and moving out of the traditional SQL world took a little thought and proving time. We'll use the first few months to learn more about doing architecture this way.

We've had the language wars - lets avoid the SQL/NOSQL wars please. I'm tired.

1. Open the browser and navigate to the page you are interested in.
2. Press the "Print" button.
3. Take your new printout, and tape it across your TV. Larger TV's might require bigger printouts.
4. ???

  Web on your TV!

I can see how this might be interesting in that it's related to a "writing class", but it's an on-line writing class! It is good to see that they are stressing some of the basics that may be somewhat lacking in some on-line (esp. non-journalistic) writing.

We had assignments to write articles for Wikipedia for several years as part of an electronic music class - each student submitted several articles (totals in the hundreds over the years the class ran) on music or music technology to Wikipedia. See http://wayneandwax.blogspot.com/2006/06/electro-class-of-06.html for more details.

Interesting - what WOULD happen if you stood in front of the Large Hadron Collider beam? Does it cut/burn like a laser, or something else? Just wondrin'...

Larry said he wrote the software to do the combining of the primitives for the trench, but what was the hardware? I've used E&S consoles similar to those, but those were VAX driven, which wasn't an option in 1976. The terminal looked similar to a VT05, but that was just an impression while watching.

For the most annoying types (scams mostly) this won't matter any. There's already a "Do not call" mechanism that's ignored. The legitimate ones will obey, the rest will just continue on.
Yes, it gives some teeth for when you actually catch them, but for the millions of us who have been getting the "Your credit rating will be affected!!!" calls lately, I doubt it will make any difference to our evening meals.

Yeah, that would bring new meaning to "Strongly Typed" that I don't think was intended...

"Damn John, that brain fart was really strongly typed!!"

Proving yet again that you can write COBOL in any language.

Seriously tho, the resulting code can't be all that great for a true Java programmer to maintain after the conversion - at its heart it would still be organized in a non-OOP (procedural) manner, which would certainly require some cross-thinking.