75

Bob Martin is clearly exaggerating to make his point more clear. But what is his point? Does he just want people to stop using SQL/Relational Databases because of SQLi attacks? To my understanding, in that blog post (your first link) Martin tries to convince people to stop using SQL, but not relational databases. These are two different things. SQL is ...


58

Bob Martin's opinion is just that; one man's opinion. A programmer is expected to understand the system he is writing well enough to exercise reasonable care about its security and performance. That means that, if you're talking to a SQL database, you do what the Bobby Tables website says to do: you sanitize your input data. It means that you put your SQL ...


50

I am uncertain how to best describe this approach when my recommendation is to continue with the existing technology stack, but implement fundamental shifts in the locations where code belongs. Service oriented architecture. You are proposing to redesign your system so that your business rules and your data are in the same place. That's effectively the ...


32

Personally, I've tried making one huge schema for all my entities on a fairly complex but small project(~300 tables) . We had an extremely normalized database (5th form normalization (I say that loosely)) with many "many to many" relationships and extreme referential integrity enforcement. We also used a "single instance per request" strategy which I'm not ...


30

REST is not CRUD. That "counterargument" is based on a fundamentally flawed understanding of what REST is. I haven't seen anything in your post that indicates your change would make your API any more or less RESTful.


28

One reason is security - if (haha! when) a hacker gains access to your front-end webserver, he gets access to everything it has access to. If you've placed your middle tier in the web server, then he has access to everything it has - ie your DB, and next thing you know, he's just run "select * from users" on your DB and taken it away from offline password ...


26

One more thing to keep in mind is the following... Not validating your business rules server side, means you implicitly trust anything that comes in, through say a POST request, is valid. Meaning that for example, while your angular application might check if the customer has a valid age range and ensures that legitimate users get the correct feedback, ...


20

Consider a company that has a few different departments: Software Development HR Accounting Can you come up with a user model that can expressively represent all those areas of business? Think of what the User entity could look like in each one. Perhaps it's split into three different entities: Developer Employee Payee The effort to instantiate a user in ...


19

There really isn't enough information, as per Thorbjørn's comments. Caching, when done wrong, can cause you & your users lots of grief. Make sure you need to worry about caching before over-complicating your application. So, in the absence of information that indicates you really need to cache, don't cache. [General rule of optimization: If you need ...


17

I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains: Product catalog, where you keep your product description and all attributes Inventory, where you have product stock level If you have one bounded context for both domains, your solution can ...


17

What is he actually saying? Is he saying replace SQL with No-SQL technologies? TL;DR: Yes (sort of) In a more recent talk than the one you linked to on basically the same topic he says: "The database is a detail. Why do we have databases?". He claims database came to be to make data access from spinning disks easier, but in the future "[...] ...


13

First, ensure that the code is partitioned in such a way that your data provider can be switched easily. We're talking interface segregation and the other SOLID principles here. Next you need to know the answer to the following: 1) Will the data change frequently? 2) Does the application poll your REST service frequently to get these updates? 3) Is the ...


13

Let me start by simple clarification: I don't have experience with such large database so the rest of my answer is not based on the real world example. So you have a BIG database and you want to use it with ORM / EF. I would go with the second choice. Here is my simple explanation why: Mapping adds complexity. There is no need to add complexity with ...


13

What you call single REST APIs might be called REST API's particular set of resources or resources. You also could look at it as REST API's functionalities. Such as any kind of software, the whole package is versioned/updated, not single functionalities or resources. Your question would make sense in the context where the REST API package's resources are ...


13

... which makes me wonder if there are any systems / architectures for defining a virtual machine without a call stack Continuation Passing Style enables tail call optimization for all function invocations — thus, no stack is needed; however, heap memory is most likely used to hold the closures capturing references to local variables. CPS is used as ...


12

Here's an even better approach: use content negotiation to version your API with the Content-Type and Accept headers: POST /api/accounts Accept: application/vnd.my-api.account.v1+json 201 Created Location: /api/accounts/285728 Content-Type: application/vnd.my-api.account.v1+json { ... account data here ... } To get a different version, merely ask for it ...


12

Service Providers, doing only one thing The core difference, which has widespread consequences of the project, is that with Microservices these Service Providers are independently deployable and scalable. This is great, because you can be more agile. If a service needs changed, you just change that one, none of its kin. If you want to try a new framework ...


12

Transactions A transaction wraps all of the required steps for a particular business operation and guarantees that either all of the steps succeed or they all rollback to the original state in the database before the transaction was started. Further Reading How are Cassandra transactions different from RDBMS transactions?


11

The most architecturally sound approach I know of is to put that single source of truth behind a microservice. It is perfectly okay for multiple parts of the system to update that data, as long as they do it through something like a microservice that can ensure it's always done correctly and predictably. So for instance, Customer data is probably already in ...


11

It depends on the widget. If the widget is rare and expensive (exactly 10 Ferraris), then the approach you're following is correct. Of course, you also need to account for inventory that's being returned but hasn't been restocked yet, inventory that's out for repair, etc. If the widget is a bit more common (5,000 wrenches) then the usual approach is to: ...


11

SQL is a detail. Knowledge of a detail should not spread. As SQL is used in more and more places in your code your code becomes more and more dependent on it. As you learn more and more SQL tricks you solve more and more problems using SQL. This means that switching to another API to persist involves more than just translating. You have to solve problems ...


11

To add to the other good answers here: Your interface, REST or otherwise, should not be constrained based on some sort of assumptions around implementation details. This is completely antithetical to the notion of services as an abstraction layer. One of the main benefits to using services is that implementation details can be changed without the ...


10

A typical multi-tier application looks like this: In an MVC application, the data tier and logic tier reside in the Model, while the presentation tier resides in the View. In between the Model and the View, the Controller provides a switchyard, routing web requests and responses to the appropriate methods, views and model logic. Within the Model, you can ...


10

Sounds like you have 3 major categories of data you are trying to store: General job data (job id, job requester id, job receiver id etc) State transitions (job started, job finished) State-specific job data (optional) job-related events (price changed, job receiver user reassigned etc) The key is to separate event-like data from everything else. Schema ...


10

Performance does neither increase or decrease because "you put most of the code into database" or because "you keep the code out of the database". The key point is to put the right parts of the code into the database (or to keep them out). Parts which helps to reduce the network traffic might be a good fit for stored procedures. Parts which do heavy ...


10

A really simple rule of thumb is that you should only use a DTO object when you need to ... transfer data. That means use a DTO at the boundaries in your web API, or when you are sending the object on a message bus. Internally, just use your domain objects. The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need ...


9

Multitenancy is a hard problem. Very hard. I've seen a lot of companies do it, very few of them having done it well. To cite just one of the many examples of where multi-tenant systems can fall apart, consider what will happen when one customers wants a data warehouse or ad-hoc reporting database. Can you spin one off relatively easily, or do you have to go ...


9

We can neither confirm nor deny such a statement. Risks, reliability and predictability Governments and large enterprise are very risk adverse and tend to prefer proven technology, that is well understood. Older technologies have more often a proven track of success and are more predictable (e.g. not a technology that will vanish before the investments ...


Only top voted, non community-wiki answers of a minimum length are eligible