The robotic cranes are coming along nicely. I completely re-worked all my logic about 3 weeks ago and so have been a little behind schedule. I’ve had the opportunity to do some really good testing recently though, and the changes I implemented are working well. The system is based on a sort of state-processor type model. This means that based on a bunch of flags that represent the state of the device decisions are made regarding the ability to do certain tasks, such as transfer, do a command (store, pull, etc.). The program falls through this logic every so often, determining all it’s state flags, and then doing things based on those flags. This sort of programming is prevalent in device controls, but was something it took me some time to get used to as the logic can get very very complex. Anyway, the purpose of this post is to express a quandary… When is it appropriate to have business logic in the database. Of course I mean as stored procedures. I see people leaning both ways on this. Some say business logic should be there because as a stored procedure it’s super fast, others say it only belongs in one place, the business logic layer. I have found myself wondering why I shouldn’t put some business logic in the database stored procs, simply because this system is such a one off, that there is no chance of code reuse. I haven’t done it yet, I guess because it just feels weird to me, but sometimes I think it would be OK, and I know it would make my life easier. Oh well.

Later,
Tim