Thanks for your advice and everybody else's too... I still feel like I may at least give SimpleDB a try by making a new domain for each table and distributing the large tables over multiple domains (my data is amenable to splitting up). I may make two copies of some domains that are split up in different ways so I don't have to query all of the domains associated with a table.
Are JOINs used that often? My thought was that I could export the data to a mysql database for analysis if I needed to do any very demanding crunching.
JOINs are awesome. They're expensive operations, no doubt, but they make creating a web application a TON easier. If you're going to limit yourself to the way that Google or Amazon has to develop web applications, you're getting rid of your primary advantage.
Let's say you have a site with logins and comments. Comments are by one of the logins with a nice foreign key in a relational database or you have to add part of that person's info to each comment with something like SimpleDB (if you want to display the name next to the comment, you place the name there). So, then someone changes their name in the logins table - it happens. With the foreign key and a join, all the comments appropriately show the correct name. With SimpleDB, you have to go through and update every single comment that person has made to reflect the changes.
Take something like Facebook. Every single mail message, every single wall post, every single friend, every single Event, every single group, etc. would have to be updated to reflect your new name if it wasn't referential. Now, Facebook probably isn't referential. They're big. They probably spend a ton of time/money keeping that stuff in sync. In fact, they probably run those types of updates as low-priority background jobs (so while your new name shows up in your profile now, it is a while before it gets propagated). That's all guessing, btw, but you can see how much more difficult it is to keep non-relational data in sync.
Places like Facebook have to operate differently because JOINs do have cost. It's amazingly unlikely that a relational database won't suit your site due to scalability. If you're looking to make a cool site, do it the easy way first, then scale. Otherwise, someone else will build it faster than you.
Non-relational data seems easy and it is for simple things. It might be that your site fits very nicely in a non-relational model. Do be aware of the differences.
Comments
Thanks for your advice and everybody else's too... I still feel like I may at least give SimpleDB a try by making a new domain for each table and distributing the large tables over multiple domains (my data is amenable to splitting up). I may make two copies of some domains that are split up in different ways so I don't have to query all of the domains associated with a table.
Are JOINs used that often? My thought was that I could export the data to a mysql database for analysis if I needed to do any very demanding crunching.
JOINs are awesome. They're expensive operations, no doubt, but they make creating a web application a TON easier. If you're going to limit yourself to the way that Google or Amazon has to develop web applications, you're getting rid of your primary advantage.
Let's say you have a site with logins and comments. Comments are by one of the logins with a nice foreign key in a relational database or you have to add part of that person's info to each comment with something like SimpleDB (if you want to display the name next to the comment, you place the name there). So, then someone changes their name in the logins table - it happens. With the foreign key and a join, all the comments appropriately show the correct name. With SimpleDB, you have to go through and update every single comment that person has made to reflect the changes.
Take something like Facebook. Every single mail message, every single wall post, every single friend, every single Event, every single group, etc. would have to be updated to reflect your new name if it wasn't referential. Now, Facebook probably isn't referential. They're big. They probably spend a ton of time/money keeping that stuff in sync. In fact, they probably run those types of updates as low-priority background jobs (so while your new name shows up in your profile now, it is a while before it gets propagated). That's all guessing, btw, but you can see how much more difficult it is to keep non-relational data in sync.
Places like Facebook have to operate differently because JOINs do have cost. It's amazingly unlikely that a relational database won't suit your site due to scalability. If you're looking to make a cool site, do it the easy way first, then scale. Otherwise, someone else will build it faster than you.
Non-relational data seems easy and it is for simple things. It might be that your site fits very nicely in a non-relational model. Do be aware of the differences.