4 ms·

For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture. How

For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture. How to design the software so that these kinds of changes can be made late and they are not a major work is also a skill to be learned.

ledauphin 7y ago
the example given is not wise to attempt to fully isolate in your architecture and design. A NoSQL database brings with it an entirely different approach to your data, and as has been pointed out many times, the core of every software system is its data. If you are choosing a NoSQL database, you should be confident you know why you are doing so, but you should not imagine (or attempt to pretend) that you will be able to isolate your code from that choice.
- kyberias 7y ago
  > A NoSQL database brings with it an entirely different approach to your data NoSQL has no specific definition, so no it doesn't necessarily bring anything different. > the core of every software system is its data. That doesn't really mean anything. One could also say that the core of every software system is its use cases. > isolate your code from that choice. It is very important to isolate code (e.g. business logic) from the specific details of how you persist your data.
mooreds 7y ago
> How to design the software so that these kinds of changes can be made late and they are not a major work is also a skill to be learned. And when it is worth the effort. To be fair to the nosql example in the post, the company in question was an early stage startup. And in those situations available skillset and time to market can and often does outweigh long term flexibility.
AmericanChopper 7y ago
> For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture. Choosing what kind of database to use isn’t really an “implementation detail” as much as it is a “major, foundational architecture decision”. Taking tabular, relational data and putting it in a document DB (which I’d be willing to bet is the most common NoSQL use case) makes about as much sense as taking the same data and putting it into a graph DB. You can make it work, but everybody who does this runs into exactly the same problems over and over again. Perhaps this is a sign of how dysfunctional some technology trends are, but I can’t see it as an indictment of software architecture in general.

ledauphin 7y ago

the example given is not wise to attempt to fully isolate in your architecture and design. A NoSQL database brings with it an entirely different approach to your data, and as has been pointed out many times, the core of every software system is its data. If you are choosing a NoSQL database, you should be confident you know why you are doing so, but you should not imagine (or attempt to pretend) that you will be able to isolate your code from that choice.

kyberias 7y ago
> A NoSQL database brings with it an entirely different approach to your data NoSQL has no specific definition, so no it doesn't necessarily bring anything different. > the core of every software system is its data. That doesn't really mean anything. One could also say that the core of every software system is its use cases. > isolate your code from that choice. It is very important to isolate code (e.g. business logic) from the specific details of how you persist your data.

mooreds 7y ago

> How to design the software so that these kinds of changes can be made late and they are not a major work is also a skill to be learned. And when it is worth the effort. To be fair to the nosql example in the post, the company in question was an early stage startup. And in those situations available skillset and time to market can and often does outweigh long term flexibility.

AmericanChopper 7y ago

> For an implementation detail (selection of database technology) to have such an effect to an organization may be a sign of defective software architecture. Choosing what kind of database to use isn’t really an “implementation detail” as much as it is a “major, foundational architecture decision”. Taking tabular, relational data and putting it in a document DB (which I’d be willing to bet is the most common NoSQL use case) makes about as much sense as taking the same data and putting it into a graph DB. You can make it work, but everybody who does this runs into exactly the same problems over and over again. Perhaps this is a sign of how dysfunctional some technology trends are, but I can’t see it as an indictment of software architecture in general.