NOSQL Design, without denormalization?

I've just started designing the 'schema' of a distributed store database.

I keep having mental debates on how much to denormalize. I understand how to do it, and why it will increase performance if the denormalization matches the queries well to minimize gathering data from multiple places...

...But, it's often said that pre-mature optim开发者_开发问答ization is bad. The advantages of a design that is relational, with references instead of duplicate data that is embedded are clear: Elegant, flexible, no worries about keeping duplicate data consistent, etc.

So I am now wondering whether it's a reasonable strategy to design the schema in a very relational way, using the application layer to gather the data as necessary, and only change this later if needed.

If traffic becomes an issue, I am already on a technology that can scale horizontally with some design changes (isolation, denormalization).

Seems like it could be the best choice among:

• start with RDBMS, move to distributed store if needed
• start with distributed store, with full denormalized design (scale-ready)
• start with distributed store with relational design, denormalize + isolate if needed

Thoughts?

Thanks

Have you considered scaling your properly normalized relational db the old fashioned way? NoSQL has gained notoriety by allowing simple or poorly designed php/lamp apps to scale by replacing the bottleneck with something crude but effective. If you have an elegant design you don't need NoSQL to scale out.

I'd go with option 2, assuming that there are no really serious disadvantages to the scalable schema.

If you know that you will probably need to use a distributed store later, you may as well go with something resembling the final system from the start rather than having to deal with multiple schema versions. NoSQL designs are not necessarily more complex than relational designs, but they are different. Many of the NoSQL platforms are now mature enough that they are as easy to use for initial development as SQL is.

You may also find that you don't need to do anything too complex to get horizontal scaling - a lot of the joins in a typical relational database are there because it doesn't support multiple values or hierarchical structures.

I think thaty the last approach sounds very reasonable, but I have some comments. There is no longer relational dbms, so I would suggest to use OO design instead of relational. For example if we have one-to-many relation, whith "owning" semantics - we can put both sides in one object and store it as one object. I think this approach can be considered perfectly "normalized" in the NOSQL word.