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.