Conclusion

I'd like to conclude this chapter by refocusing your thoughts on what matters most in my opinion: make database architecture decisions based on logic as much as you can, instead of basing them on keeping up with the Joneses or doing something that feels good or cool. A while back, David Fetter and I were having a conversation on IRC. He's a PostgreSQL user and consultant, just as I'm a MySQL user and consultant. Can you see where this is going? I'll paraphrase a bit, to avoid the holy war: we decided that most people choose one database or another based on how they feel about it, rather than on its technical merits.

Similarly, I believe most people make choices about programming languages, database architectures, and other technologies based on what makes them feel happy and safe and productive, or even what makes them feel cool.

We do this because we're human. I am not here to make your life less fun, really. But I encourage you to build your own application, and don't chase after coolness or reinvent the wheel.

Try to build small, not big—go only as big as you're forced to. Determine the application's true requirements, and try to match those as well as possible. Stay away from things that seem clever, in favor of things that have proven to work well. Don't rely on unreliable things, such as DNS. Accept that the state of the art is sometimes lagging, and databases have a long way to go before you'll have a perfectly scalable cluster that just makes all your problems disappear. ...

Get Web Operations now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.