4 ms·

I'm confused. Is the author trying to convince me to give up the expressivity, portability, and readability of my Python app-layer codebase for the performance

I'm confused. Is the author trying to convince me to give up the expressivity, portability, and readability of my Python app-layer codebase for the performance gains to be had by writing my logic in stored procedures? Having moved one codebase OUT of T-SQL stored functions and onto Django's ORM, I can say that this article does not have me convinced the way forward is to move the code back INTO the DB. If my data model is going to be dictating my development toolset, it better be giving me some amazing performance gains and be as good as the toolset I've come to enjoy in a post-ruby-on-rails-world. What am I missing?

pron 14y ago
You don't have to give up anything. These "stored procedures" are not what you think they are, and neither is the database. The idea is that the db and the application become one - not that you have to program in plsql or something. You could continue to use python or ruby. And yes, the performance gains are amazing.
nobodysfool 14y ago
You're missing ten thousand spaceships. He's gained performance by not returning a resultset for something that is just going to get written back to the database anyway. Normally, if you are writing a program, you get all the data from the database, then do some logic on it to determine what's going to happen. Say for example you store everything it the database regarding a million objects, and you want to have the ability for them to collide with each other. You'd get those million objects, then in your app layer, check if they are close enough to collide. What he's doing is using the database to determine if they are close enough, and then calculating the collisions in the database itself. I think if you just used the database to determine how close things are, and then switched to the app layer to do the appropriate collision calculations, you'd have a more configurable app. 10fps for 10k spaceships interacting with each other is not too shabby for a database. I'd rather not have so many updates in my database though, and I'd be okay with the fact that if my app crashed, the battles would have to start over again about 5 minutes in the past. However, you aren't writing games in Django's ORM that need realtime updates, so in your use case, it wouldn't make sense.

pron 14y ago

You don't have to give up anything. These "stored procedures" are not what you think they are, and neither is the database. The idea is that the db and the application become one - not that you have to program in plsql or something. You could continue to use python or ruby. And yes, the performance gains are amazing.

nobodysfool 14y ago

You're missing ten thousand spaceships. He's gained performance by not returning a resultset for something that is just going to get written back to the database anyway. Normally, if you are writing a program, you get all the data from the database, then do some logic on it to determine what's going to happen. Say for example you store everything it the database regarding a million objects, and you want to have the ability for them to collide with each other. You'd get those million objects, then in your app layer, check if they are close enough to collide. What he's doing is using the database to determine if they are close enough, and then calculating the collisions in the database itself. I think if you just used the database to determine how close things are, and then switched to the app layer to do the appropriate collision calculations, you'd have a more configurable app. 10fps for 10k spaceships interacting with each other is not too shabby for a database. I'd rather not have so many updates in my database though, and I'd be okay with the fact that if my app crashed, the battles would have to start over again about 5 minutes in the past. However, you aren't writing games in Django's ORM that need realtime updates, so in your use case, it wouldn't make sense.