Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on What is a good modern language to use for a Business Rules project?

Parent

What is a good modern language to use for a Business Rules project?

+9
−0

This is a rather vague question, but I'm trying to solve a specific problem and I'm inexperienced in most of the potential solutions, so please forgive the inherent ambiguity.

I have access to a database with millions of historical financial transactions, with new transactions being added every day. Based on these transactions I want to apply several hundreds of business rules. These could be things like, "apply sales tax per lookup table based on city and state," or "record commissions based on the internal salesperson and their commission rate." It could also include things like, "bill client X twice per month between April and October at rate R1 for type A transactions and rate R2 for type B transactions, and a flat $100 per month from November to March."

Eventually I'd like for the business rules to be programmable via a web interface, but that's unnecessary at the beginning. My main concern is creating a system that is reliable and flexible enough to handle this level of complexity while still being relatively maintainable and comprehensible.

Unfortunately, it seems that COBOL is one of the most popular languages for this kind of problem, but I'd rather not go that route. I've used R and SQL at much smaller scale in a similar problem space, but it wasn't ideal. I'm familiar in passing with BREs like Drools, but have never actually worked with them, and my general perception is that they are often difficult to maintain.

I don't mind learning a new stack for this project; Go, python, or Rust have all caught my eye in the past. But I keep wondering if I'm missing something that has more inherent support for this use case.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Programmable by whom? (4 comments)
Post
+2
−1

SQL is the right tool for this job.

  • You say the data is already in a database, probably a SQL database
  • You don't have to deal with moving the data out of the database and "into a programming language" as you would with others
  • This is an extremely common application of SQL, and you will find a plethora of relevant examples, guides and tools (including web based editors) online for it
  • Many SQL engines have sophisticated query optimization features that will automatically improve the performance of your queries while you focus on the result you want

You say your experience using SQL was not ideal. I'm baffled. There are billion dollar businesses that run on the premise that it is, in fact, ideal. Your examples sound to me like classic SQL exercises. I would recommend you take each example rule, and ask a separate question like: "How to apply sales tax per lookup table based on city and state in SQL?" By the way, for something like that, you will need to find a lookup table of taxes by location - that will often also be available as a SQL DB from third parties.

Note that you also mention recurring processes, like "twice per month". This is a scheduling problem and no language supports this out of the box. You will have to use a separate scheduler that will have its own peculiarities, to actually put tasks on a schedule. Some examples include cron (becoming obsolete), systemd timers, Airflow. Some database engines also have a concept of scheduled tasks/jobs.

For other languages you listed:

  • Python is probably the easiest after SQL. You will still have to deal with database I/O as a needless extra step, however some very complex rules may be easier than in SQL. It really depends on what rules exactly you need to implement. I said you should ask how to do each example in SQL, you should also ask for Python and compare the answer to decide what you'd rather deal with. Python is a very complex and sophisticated language, compared to SQL, don't be deceived by its apparent simplicity.
  • R will require some busywork to push/pull data from the database. The syntax for data manipulation will be a bit more complex and cumbersome than SQL in your case, with little benefit. The benefit of R is its extensive, correct implementations of statistical and data analysis formulae, and powerful plotting libraries. You are using neither of these and IMO it's not worth it for you to deal with its limitations.
  • Rust is a language designed to provide tight control over the low-level details of programs, like memory assignment. Its benefit is potentially better performance, and drawback is that high-level tasks require a lot more code and complexity to implement. I would consider it a terrible choice for what you want to do. Go is similar, although it is slightly less low level.
  • COBOL is ancient, it would be masochistic to attempt to use it in this century.
History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

I think MySQL falls short of OP's core requirement to be reliable and maintainable. It needs to be po... (2 comments)
I think MySQL falls short of OP's core requirement to be reliable and maintainable. It needs to be po...
abhibeckert‭ wrote 9 months ago · edited 9 months ago

I think MySQL falls short of OP's core requirement to be reliable and maintainable. It needs to be possible to verify the code actually does what the business rules require.

Calculating tax for example can be extraordinarily difficult to the point where it's often not even possible to calculate at all - for example is a hot air balloon involved in the transaction? Is it in the state of Kansas? Then it's tax exempt. I kid you not. These issues often require data input by humans, review by other humans, etc which means you need a proper user interface/etc and can't just work with the raw data. You also need to be able to handle partial input, you need to be able to make batch changes retroactively to fix human errors, etc etc.

Yes, some things are one line (or even one word) in SQL that would take a dozen lines in other languages. Yes SQL might be faster. Those advantages aren't enough to make SQL the right choice.

matthewsnyder‭ wrote 9 months ago

I think the discussion of how to implement a comprehensive tax calculator is a separate issue from this question. Unless I've missed something, OP does not say that he is specifically trying to build a TurboTax alternative. The examples he gave sound like some kind of billing/transaction processing system, which is not extraordinarily complex, and SQL is a good way to implement that.

Regarding MySQL, do you mean the MySQL engine specifically, or are you trying to say that all SQL is inherently not reliable/maintainable? My answer doesn't mention MySQL, and to be clear I'd use maybe SQLite or Postgres instead (although choice of SQL engine should be a separate question). But I'm curious why you feel it's not reliable or maintainable.