12 ms·

Having so many database choices is something of an embarrassment of riches. So many options, but also so much stress for the software architect who hopes to mak

Having so many database choices is something of an embarrassment of riches. So many options, but also so much stress for the software architect who hopes to make the right choices. Its impossible for someone to be so familiar with each option so as to anticipate future issues that may arise because of a missing piece of functionality or other strange quirk. Something made worse when you go down the proprietary route. I prefer to stick with one single reference data store, be it MySQL, Postgres, SQL Server or whatever. If we need to add some kind of search optimised database or big data analysis database they should replicate from the reference data store and be treated as non-mission critical add-ons.

sokoloff 8y ago
There are cases where that strategy doesn't work effectively (IMO). Consider a social graph or purchase history relationships in a graph database. You could restrict your engineering team to only make entries in a (relational) reference data store and then express those relationships in a graph DB for querying. That is not likely to give you the same pace of development as a competitor who chooses to use a graph DB natively while your team goes through a labor-intensive translation or impedance-matching process for each change. If they're able to outpace you in development/innovation, you are more likely to lose in the market.
- golergka 8y ago
  > If they're able to outpace you in development/innovation, you are more likely to lose in the market. These things always depend on business requirements. What relational database offers, above all others, is data consistency: if used properly, it's an incredibly useful safety net that prevents you from errors that corrupt user's data. Transactions and especially proper schema can catch a lot of bugs that could otherwise wreak havock. So, it's a trade-off: how bad, from a business perspective, would some data corruption be? If you're Tinder, mixing up profile information or deleting a match is probably not that bad. If you're dealing with other people's money, on the other hand, it could destroy your entire business.
  - diroussel 8y ago
    Do relational databases really give you consistency? They can do if you are careful how you write your app. And many people don't use serialisable transactions because of the implications. Also relation databases enforce their version of consistency. What if I only want consistency within one customer's data but not all customers? I could have two inserts for operations on two different customers fail because of a deadlock on page slips in a secondary index. I didn't need that consistency but the database didn't know that.
- fauigerzigerk 8y ago
  This is a possible but not very likely scenario. It depends on your data serving a single purpose and continuing to serve a single purpose indefinitely. In my view, the reason why so many people are returning to relational DBMS for the primary data store is that data tends to live longer than you think and serve more than one purpose over time. Choosing the "right tool for the job" is easier said than done if the job keeps changing.
- coding123 8y ago
  Nah, the team that builds the entire product in neo4j or orientdb might find the entire product blowing up, instead of the find a friend d feature. I find running a spark job on the 2 columns needed to build the graph a much better usage of time.

sokoloff 8y ago

There are cases where that strategy doesn't work effectively (IMO). Consider a social graph or purchase history relationships in a graph database. You could restrict your engineering team to only make entries in a (relational) reference data store and then express those relationships in a graph DB for querying. That is not likely to give you the same pace of development as a competitor who chooses to use a graph DB natively while your team goes through a labor-intensive translation or impedance-matching process for each change. If they're able to outpace you in development/innovation, you are more likely to lose in the market.

golergka 8y ago
> If they're able to outpace you in development/innovation, you are more likely to lose in the market. These things always depend on business requirements. What relational database offers, above all others, is data consistency: if used properly, it's an incredibly useful safety net that prevents you from errors that corrupt user's data. Transactions and especially proper schema can catch a lot of bugs that could otherwise wreak havock. So, it's a trade-off: how bad, from a business perspective, would some data corruption be? If you're Tinder, mixing up profile information or deleting a match is probably not that bad. If you're dealing with other people's money, on the other hand, it could destroy your entire business.
- diroussel 8y ago
  Do relational databases really give you consistency? They can do if you are careful how you write your app. And many people don't use serialisable transactions because of the implications. Also relation databases enforce their version of consistency. What if I only want consistency within one customer's data but not all customers? I could have two inserts for operations on two different customers fail because of a deadlock on page slips in a secondary index. I didn't need that consistency but the database didn't know that.
fauigerzigerk 8y ago
This is a possible but not very likely scenario. It depends on your data serving a single purpose and continuing to serve a single purpose indefinitely. In my view, the reason why so many people are returning to relational DBMS for the primary data store is that data tends to live longer than you think and serve more than one purpose over time. Choosing the "right tool for the job" is easier said than done if the job keeps changing.
coding123 8y ago
Nah, the team that builds the entire product in neo4j or orientdb might find the entire product blowing up, instead of the find a friend d feature. I find running a spark job on the 2 columns needed to build the graph a much better usage of time.