View Poll Results: How do you do your datafeed grunt work?
- 12. You may not vote on this poll
Stored Procedures ( MySQL, Oracle, etc )
Application ( PHP, ASP, JAVA, ASP.NET etc )
January 4th, 2010, 03:07 PM #1
Stored Procedures or not?
- Join Date
- November 3rd, 2009
I'm curious to know if those of you working with datafeeds use stored procedures (MySQL, Oracle or any other rdbms) to import/update products or do all the logic and evaluations with your programming language of choice and the run simple INSERT/UPDATE queries.
You personal views on this choice are really welcome.
If would be interesting to know also why you decided one option and not the other
January 4th, 2010, 06:40 PM #2
Just really never seem to have the need to learn about Stored Procedures since a little PHP seems to be all I need. Maybe this thread will show me why I need to learn.
January 4th, 2010, 09:23 PM #3
I haven't heard of anybody using stored procedures for this.Hatred stirs up strife, But love covers all transgressions.
January 5th, 2010, 06:05 AM #4
January 5th, 2010, 08:45 AM #5
So, when you start out with datafeeds, the problem may seem pretty simply. You will soon find that most datafeeds are horrible crap and you are fighting bad data all the time. You will need lots of application level code to deal with all the issues that arise, if you want to build a decent product.Merchants, any data you provide to Google Shopping should also be in your affiliate network datafeed. More data means more sales!
March 13th, 2010, 12:01 AM #6
April 15th, 2010, 12:49 AM #7hoodoos commune
Also, keep in mind that by using a stored procedure, you're more likely to pass parameters, and not concatenate your arguments.
exec ups_MySproc( @arg1, @arg2 ) (good)
insert table (col1) values (" + mydata + ")" (very bad).
This is how SQL injection happens.
April 15th, 2010, 08:17 AM #8
- Join Date
- October 5th, 2008
I would say you definitely do not need stored procedures. Originally people used them because they were faster but many modern databases optimize normal SQL to the point that speed is not a major factor.
The issue I have with stored procedures is it puts your application logic in the database. This in turns makes it very difficult to switch databases or modify your application logic.
With PHP or any scripting/programming language you can just write a function to handle any data manipulation before calling your INSERT or UPDATE with your modified data.
Also, related to @Dave123 sql injection statement, PHP supports safe escaping of variables without needing to use stored procedures. The trick is to escape any human entered parameters so they can't pass in unwanted SQL. It's been a while since I have written PHP SQL or I would show you an example. If you are just processing feeds the risk of sql injection is close to zero since you are running a merchants feed, not data entered by a web form.
April 15th, 2010, 05:29 PM #9
Its a pretty old debate: this link sums it up nicely.
both sides make good arguments. What I see is that MSFT tech folks have been taught to use sprocs, java and lamp folks tend not to.
In my opinion, the audience here is probably not a three-tier (web/data/db layer) style of development. Its probably web tier-to-db (with outliers, of course). At the end of the day, its not really going to amount to much whether you create procs or use direct sql.
I suppose I would try to change the topic to be about more impactful best practices. If someone has only been developing for a couple years, and pulls most their code off of google searches, they're much more likely to make write code that adds a security hole that ends their business. Making the wrong call on Sprocs vs. sql might add a little maintenance overhead, but it won't end you.
By boningroup in forum GoldenCANReplies: 5Last Post: January 25th, 2007, 11:30 AM
By sammiethecat in forum Virtual Family and Off-TopicReplies: 5Last Post: February 14th, 2006, 10:28 AM
By cyclone in forum Commission Junction - CJReplies: 5Last Post: December 11th, 2002, 01:14 AM