There are two ways to write error-free programs; only the third works.
Alan J. Perlis
I am doing a startup!
Cross-browser testing from your browser!
I have written my fourth book!
Be faster than Larry Wall in the shell!
You're viewing a comment by David and its responses.
ORMs are just making things more complicated. It's not a big deal to write SQL statements. Also logging is not a big thing, maybe you could save typing some code, but that would take only an hour or so.
Hmm David, I would like to test your apps againt SQL injection. Would be intresting. ORMs are great when it comes to the point of code reading or efficiency. When you avoid ORM you just making your life harder.
You don't need an ORM to avoid SQL injections. All you need is to encode the query params. And then? That's it.
The advantage of an ORM is *just* to make it look like a bad OOP language. Everybody should know that SQL != OOP. Each technology needs to be used appropriately.
ORM and efficiency should never be used in the same sentence.
Obviously you never came across the concept of being platform independant..
Can you please elaborate, like, how is SQL platform dependent and ORM is not. I don't understand where you are pointing with your sentence.
I was using an ORM and I learnt SQL just yesterday and now I don't know what all the fuss is about. To defend against SQL injection you only need to call a function. So you have more lines of code, but that's it.
So basically you copy&paste that line all over your code?
Copy&Paste programming is bad, okay?
You are sure to mess up sooner or later, and if not you, then the maintenance programmer who has to keep your stuff running after you left the company (or the project or whatever).
Boilerplate code is bad, too, okay?
Ideally, each line of your code does something important, and functions and objects abstract away any details below the detail level of your code at that point. That (and a number of other things) makes code readable and maintainable.
At best your extra lines take up monitor space needlessly. At worst they distract from or even drown out what your program really is supposed to do. (IDE code generators are quite like snorting acids up your nostrils to deaden your sense of smell against the stink of boilerplate code.)
Finally, the *correct* way to handle SQL injection is always using place holders in your query (and binding any variable data to them).
Not only is that pattern distinct (and more noticeable when not used), it also allows the DB to compile, cache and optimize the query. That comes handy when you handle larger amounts of queries and data --- i.e. when bad database performance is most noticeable.
So the only defensible answer would be: "I use a single function/method/routine/... that handles all SQL queries and their input data and there all the data is escaped before it enters the query."
Wow, you heard of SQL injections. Here is a star, bro. Now, can we continue with productive arguments, please? SQL injection is not a problem inherent to use of SQL as such. It is partially relevant when user is able to compose their own SQL queries, for malicious or other use. Talking in favor of ORM because it eliminates the threat of SQL injection makes you sound like a cool weekend hacker on a weekend hacker conference. All the other hackers will clap and tap you on the shoulder because you namedrop all the cool buzzwords, but a computer scientist will just recall why he went to college instead, where he learned what potential advantages and disadvantages of ORM and SQL are.
"When you avoid ORM you just making your life harder." -- I think what you wanted to say was "When _I_ avoid ORM, I just making my life harder." Don't impose your limitations on others.
Also, read up on ORM mapping problems. I am sure you don't have them, probably because you don't take your underlying data model into account, but some of us do care.
Dave, in all honesty, I think you should accept Catmans proposition -- free test for SQL injections, man, that stuff don't arrive in the offer box every day.
Sorry but this is a very stupid statement. Then why use a high level programming language at all? C is not that difficult.
Abstraction is important.
C is certainly not difficult, if you're careful enough. You don't need to learn a lot of concepts to understand it. You just need good coding skills to use it.
Use a high level language if you want more productivity. It's the same with ORMs: you can get more productivity, but then your software won't be so elaborated. It may be fine for some people. I would say that the difference is that there are more drawbacks of using ORMs than a high level language.
(why do I need your e-mail?)
It would be nice if you left your e-mail address. Sometimes I want to send a private message, or just thank for the great comment. Having your e-mail really helps.
I will never ever spam you.
(Your twitter handle, if you have one.)
* use <pre>...</pre> to insert a plain code snippet.
* use <pre lang="lang">...</pre> to insert a syntax highlighted code snippet.
For example, <pre lang="python">...</pre> will insert Python highlighted code.
* use <code>...</code> to highlight a variable or a single shell command.
* use <a href="url" nospam>title</a> to insert links.
<a href="url" nospam>title</a>
* use other HTML tags, such as, <b>, <i>, <blockquote>, <sup>, <sub> for text formatting.
Type the word "lcd_508": (just to make sure you're a human)
Please preview the comment before submitting to make sure it's OK.
Peter Krumins' blog about programming, hacking, software reuse, software ideas, computer security, browserling, google and technology.
Reach me at:
Or meet me on:
Subscribe through an RSS feed:
Subscribe through email:
Enter your email address:
Delivered by FeedBurner
See all top articles
See all downloads
See more detailed list of recent articles
See more detailed category information
See more detailed list of all articles