Tuesday, June 23, 2009

More speculation...

... in the vein of this.

Jesus says in Mark 11:23 I tell you the truth. Anyone may say to this hill, "Go and jump into the sea." He must not doubt in his heart, but he must believe that he will have the things he asks for and he will have them.

What if Jesus didn't mean "if you have faith, I will move the hill (mountain) for you", but "if you have faith, the hill will move because the Universe was built to respond to human volition"? We know that the human body responds to human will sometimes (placebo effect); there's a speculative part of physics (quantum physics) that has as a basic tenet that human observation can influence the outcome of physical processes.

Why the need for "unwavering" faith, then? Well, the Universe is probably a simple mechanism, if you're not very sure of what you want it cannot respond to your will. Maybe there's a "faith threshold" that triggers the mechanism; or maybe there's a required ratio between the "amount" of faith and the desired effect (so less faith would be required for moving a pin than for moving a mountain).

As I said - speculation; it's not something I actually believe, for now it's just an amusing idea.

Thursday, June 04, 2009

On extending DBMSes

Problem: you have some data for your company. The data has to be accessed from multiple applications (think accounting, personnel, sales and so on). How do you make sure business rules are obeyed - because if there's a bug in even one application, it will ruin the data and thus every other application.

I agree with pretty much everything Fabian Pascal has to say about relational databases. The RDB *is* the place where data should live, and ideally it should be the place for business logic too - because business logic is about data.

However, there are a few problems with this - mainly because of a lack in implementation, not in the theory of the relational database:


  • No existing DBMS (Database Management System) - the actual implementation of the relational database theory - can support thousands of concurrent users, let alone millions.

  • It is hard to do user management / authentication in the same database as your business data - in fact, it might be a good idea to have separate databases for users (think Active Directory) and the actual data you care about.

  • The SQL language sucks for general purpose programming. It is difficult to write complex business rules in, and even more difficult to port to another vendor.



For these reasons, one should write an application whose main purpose is to "guard" the (main) database and enforce the business rules; think of it as "extending" the DBMS. [1] All other applications should go through this "gatekeeper" application.

I guess this is some sort of "pattern" - an architecture that can be used to solve a number of problems.



[1] Note: some DBMSes allow you to write "plugins" or "user functions" in a different language. The problem is, these are also not easily portable, so I would recommend against it.