Web development frameworks and SQL ghettos. 2
My platform of choice is Ruby on Rails.
In an early project, I implemented some reports by coding special purpose sql statements embedded within model methods. This worked well, and allowed the reports to run reasonably speedily.
As I continued to maintain the application and requirements changed, I found that I was reluctant to change the way the model objects interacted as it would require not only changing the model code, but sifting through the mounds of complex and convoluted sql.
What had been an efficient way to handle a problem (generating the reports quickly but in coding time and in runtime) had resulted in ‘scar tissue’, or maybe a fossilisation of my object model structure within the body of the sql.
Over time, this caused me to change the way I was altering the design, by forcing me to add layers around classes instead of refactoring within them.
After I finished on that project, I reviewed what I had done and vowed never to create sql ghettos again.
I think it is an apt term ‘sql ghetto’. An area in your application that you almost dare not go. that hinders future development, forcing it to work around it.
Resist the temptation to make ghettos, for they will surely come back to haunt you.
Your problem though was using ActiveRecord and needing better speed than could be achieved by using the default behaviour. If you hadn’t made your ghetto how would you have fixed that?
Well,
I am not saying there was a solution to the speed problem that would not ghettoize that part of the system. But I am saying that the ghetto itself became a significant burden on the project.
It is more a cautionary tale than a commandment.
Since then I have been on projects where inexperienced rails developers have pushed to make use of find_by_sql very early on, and have always cautioned them to try to keep the system in ‘rails space’ instead of ‘sql space’.
Sometimes it is not possible, but as a general principle it is something not to be ignored.