3

Let us say that for a web application, inside the source code of the app you created a function called calculateAmount. Inside the web app, you need to call that function.

But for some reason, due to the need for 'automation', you want the app itself to 'think for itself', at which stage of the program, which function need to be executed.

For example, when a user of the app is perfoming 'Action A', the function calculateAmount is called. When user of the app is performing 'Action B', another function calculateTax is called.

First idea: For the effect of 'automation', I was taught that one can simply store the function names calculateAmount, calculateTax inside a database table. Then when the web app is running, at different stages of execution, your web app makes a call to the database in order to know which function need to be invoked, based on the result you get from the database table.

Second idea: Just as an example we say calculateAmount is a javascript function like the one below:

function calculateAmount(paramA,paramB){
  return paramA + (5/100) + paramB;
}  

Again, because of 'automation', I was taught that one can simply store the function body return paramA + (5/100) + paramB; inside a database table. Then the web app can simply 'think for itself' and when it needs to call the calculateAmount function, the web app makes a call to the database, and retrieve the function body from the database table and can execute any function whenever the correct situation arises.

My question is whether the above two ideas is very commonly practiced? Is there a situation where the above practices can have a negative impact on the performance of the database or the web app?

EDIT: And the overall picture that someone was trying to promote to me is that you can store many things inside a database.If a software developer can do this well enough, there is less reliance for developer(s) to write source code. This is because, configurations,name of function, function body can be stored in a database. Instead of relying on many developer(s) to write source code, you can rely on the software to think for itself at which point of time what source code should be executed and retrieve it from the database accordingly.

If an entire software product can be architect in this manner. I believe the person who was trying to teach me this philosophy has a belief: Once the development and testing is complete. The software product itself is not very hard to maintain and customise. Because 'a lot' of the essential 'blocks' of the software 'lives inside the database' and to change or maintain the software. One can simply just edit the data inside the database.

2
  • 4
    It's very unclear to me what you mean by "think for itself." You've described a scenario in which your application needs to branch based on user input. This is not at all uncommon. Please tell us what problem you're actually trying to solve.
    – svidgen
    May 24, 2020 at 4:07
  • 3
    @jinchengteo: That person is wrong, to put it bluntly. Storing code in a database will not make the system "think for itself" any more that having the code in regular source files. And it will not make debugging and maintenance simpler - if anything it will make it more complex, since development tools are designed to work with source files, not database tables.
    – JacquesB
    May 25, 2020 at 7:45

2 Answers 2

7

It seems someone gave you an explanation you did not really understand, and now you ask strangers on the internet if they can give you a better one? Well, I don't know that company or product, but from what you wrote let me make an educated guess what could be the real motivations behind this architecture.

If a software developer can do this well enough, there is less reliance for developer(s) to write source code.

That is frankly said, nonsense. Such code has to be developed, tested and deployed, it does not matter if it is stored in a DB or somewhere else.

Instead of relying on many developer(s) to write source code, you can rely on the software to think for itself.

Storing code in a db allows the customer of a system to rely on other developers than the ones who maintain the regular source code, not less developers. That is a form of customization, and it does definitely not make the software "think for itself", that picture does not fit.

Once the development and testing is complete, the software product itself is not very hard to maintain and customise

The software does only get "simpler to maintain" from the vendor's point of view because they are shifting the responsibility for certain maintenance tasks to the customer. In scenarios where

  • the vendor has a reponsibility for the source code files (probably by contract)

  • the customer is responsible for his own data inside the database, but not for any source code files

it may be simpler and less effort for the customer to implement certain customizations by themselves and store them in the DB. This approach can be used to clarify the boundaries of what the vendor provides (and maintains in case of a defect), and what the customer has to provide (and to maintain by themselves in case of a defect).

But the overall effort is not saved on the development & testing side, it is just shifted to someone else.

is there a situation where the above practices can have a negative impact on the performance of the database or the web app?

Sure there might be scenarios where the customized code has to be executed very often, and when that part of the program always pulls the code again and again from the db whenever it is required, without any buffering, this could have some negative performance impact, in theory. But if that matters in reality, and if it could be optimized to the point where it does not matter any more, is a completely different question which cannot be answered in general. As always when it comes to performance, one has to look at the real system and measure.

I guess one should be more concerned here over security issues: by changing the responsibility for writing certain parts of the code from the vendor to the customer, the number of people who can manipulate the behaviour of the system grows. If some of them have malicious intents, you can imagine what might happen when you allow them to place arbitrary code in the system.

Another thing which I would put an eye one here is the testing and versioning strategy: if the code inside the DB does not follow the same testing and versioning procedures like code outside the db, that could lead to a scenario where

  • someone could make a change in one function in the DB,

  • introduces accidentally a bug

  • introduce calculation errors directly in the production system (without any prior testing)

  • then fixes the bug (but not the wrong calculation results)

and nothing of that history is documented anywhere in source control.

Hence I would be very careful for which functions I would introduce this form of customization - otherwise it can become easily a new source of errors which are hard to spot.

2
  • thank you very much for your patience :) May 24, 2020 at 14:05
  • 2
    I worked on a product that stored lots of code in the database. Turns out that customers weren't interested in writing the code, meaning we had to do all the work anyway, in a very disjointed way that was exceptionally hard to test.
    – cbojar
    May 25, 2020 at 16:22
0

First approach: all your code belongs to your repo uniformly, and is deployed in a reasonably uniform way. It's also hard to inadvertently modify when deployed. This gives more reliability and less flexibility.

Second approach: some of your most important code needs to be deployed in different ways, and can be modified at runtime by updating the DB. This gives more flexibility at the expense of more complexity and less predictability.

Choose what matches your goals best.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.