php-general Digest 17 Feb 2013 16:00:54 -0000 Issue 8126
php-general Digest 17 Feb 2013 16:00:54 - Issue 8126 Topics (messages 320230 through 320230): OOP to run sequential SQL queries? 320230 by: AmirBehzad Eslami Administrivia: To subscribe to the digest, e-mail: php-general-digest-subscr...@lists.php.net To unsubscribe from the digest, e-mail: php-general-digest-unsubscr...@lists.php.net To post to the list, e-mail: php-gene...@lists.php.net -- ---BeginMessage--- Dear list, We have a bunch of SQL-queries, they should be executed in a sequential order, with a defensive programming style in mind. We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html Now we're going to carry on in PHP, and my experience says that we should write the solution in a procedural-style, instead of OOP. Is there any benefit to use OOP in these situations? Please share your thoughts. Thanks, -behzad ---End Message---
[PHP] OOP to run sequential SQL queries?
Dear list, We have a bunch of SQL-queries, they should be executed in a sequential order, with a defensive programming style in mind. We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html Now we're going to carry on in PHP, and my experience says that we should write the solution in a procedural-style, instead of OOP. Is there any benefit to use OOP in these situations? Please share your thoughts. Thanks, -behzad
Re: [PHP] OOP to run sequential SQL queries?
Am 17.02.13 17:00, schrieb AmirBehzad Eslami: Dear list, We have a bunch of SQL-queries, they should be executed in a sequential order, with a defensive programming style in mind. I don't understand what you want? Queries are executed sequentially or do you plan to create a multi-process PHP application? We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html Now we're going to carry on in PHP, and my experience says that we should write the solution in a procedural-style, instead of OOP. Is there any benefit to use OOP in these situations? Please share your thoughts. Thanks, -behzad -- Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.biz signature.asc Description: OpenPGP digital signature
Re: [PHP] OOP to run sequential SQL queries?
Hi, We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: The article shows only one thing. that common practice should be to 'do everything where it belongs' If you implement this practice within your application, it becomes more maintainable, more performant and easier to develop. Also, to determine the styles used to write your code, is almost entirely dependent on a few things: * Programmer's preference * The problem you are solving * The standards that are commonly used in the environment you are in Is there any benefit to use OOP in these situations? Benefits of OOP are that it becomes easier to implement a more standardized code structure, better match with reality, clearer code, more structure, re-usability, and a modular design. These can all be done in procedural code as well, the difference being you need a different mind- and skillset. HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl Convince Microsoft! They need to add TRUNCATE PARTITION in SQL Server https://connect.microsoft.com/SQLServer/feedback/details/417926/truncate-partition-of-partitioned-table 2013/2/17 Marco Behnke ma...@behnke.biz Am 17.02.13 17:00, schrieb AmirBehzad Eslami: Dear list, We have a bunch of SQL-queries, they should be executed in a sequential order, with a defensive programming style in mind. I don't understand what you want? Queries are executed sequentially or do you plan to create a multi-process PHP application? We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html Now we're going to carry on in PHP, and my experience says that we should write the solution in a procedural-style, instead of OOP. Is there any benefit to use OOP in these situations? Please share your thoughts. Thanks, -behzad -- Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.biz
Re: [PHP] OOP to run sequential SQL queries?
On Sun, Feb 17, 2013 at 10:00 AM, AmirBehzad Eslami behzad.esl...@gmail.com wrote: We have a bunch of SQL-queries, they should be executed in a sequential order, with a defensive programming style in mind. We were thinking to implement the solution as Stored Procedures instead of a PHP solution that runs SQL queries, but an article in Coding Horro recommendeds to avoid SP for good reasons: http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html As has been said, everything has it's place, every tool has it's use, but we've all used that screwdriver to both open a can of paint and then bang on the lid with handle to get it closed again. Meaning that just because there's a tool to hand, it doesn't always mean it's the right thing. I tend to use stored procs when what I need to get accomplished resides well within the database and utilizes the database engine more effectively, and when such activities might become I/O bandwidth issues if it were all done serially within the application. In other words, very few and far between. If the dataset is large and involves some very complex queries (lots of nested selects and so on), it is often better as a stored proc. But there is a caveat there as well in that often times the skill sets for maintaining complex SQL code can be a lot harder to find and acquire than the skill set for maintaining the same logic in PHP. So, no absolutes, one way or another. Now we're going to carry on in PHP, and my experience says that we should write the solution in a procedural-style, instead of OOP. Is there any benefit to use OOP in these situations? Please share your thoughts. This is actually a very similar question: again, no absolutes. An OO approach is well fit for some aspects of implementation, and a procedural approach to others, and then there is the functional approach, which is yet another way of looking at the problem. Even with that, all three can come into play in any given application. What is to be gained by using an object approach, versus procedural, versus functional? If it's a fairly confined operation, perhaps wrapping it in an object might give some more portability, and if the rest of the application utilizes an object approach, would be a good way to go. If the rest of the application is primarily procedural, then introducing an object approach might become more of a maintenance issue. So, really, it's not a simple answer. There are far too many considerations. Other things to consider: does the entire series of queries need to be performed in a locked state, i.e., if the database records change during the series of queries, will things break? This has very huge performance considerations, and should be taken into account. One of the purported uses of stored procs is that it's easier to implement an atomic operation such as that, but that's really not entirely accurate either. It's quite possible to lock and release while still running the queries sequentially from code. The round-trip factors of I/O do weigh more heavily here. My overall suggestion: Do it the simplest way you can right now, measure, charaacterize, look at how the whole app operates, and refactor what needs to be refactored when you have some actual performance data. Recognize also that simplest is pretty subjective based upon you and your fellow devs experiences and points of view. A super DBA person might be able to snap off a stored proc in no time; while an experience PHPer might be able to do the same procedurally. It doesn't mean either one is better than the other. Only putting it into play and actually measuring it will do that. Stumbling over how best to do something is very often less optimal than just implementing and seeing for yourself. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
