|
Nemanja Trifunovic wrote: That is what makes "raw" SQL a major source of security problems.
That's what makes lack of knowledge about SQL and programming the source of security problems. According to your logic, C++ must suck too because you can create buffer overrun in it if you don't know what you're doing.
|
|
|
|
|
|
I addressed your answer already too. 
|
|
|
|
|
PedroMC wrote: it's not that bad!
Agreed.
|
|
|
|
|
PedroMC wrote: seeing the amount of effort that goes in to hiding it
This may be because the major DBMS each have their own SQL dialects.
In my last project, we wrote an application that was designed to interact with any database whatsoever. The project lead (which wasn't I) decided to do this by using pure SQL and therein only the ANSI-SQL standard. Believe me, it was a pure horror when it came to things more complex than a simple SELECT x FROM y ORDER by Z. That's why so many people want to get rid of the SQL stuff: It is very painful in practical use.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: It is very painful in practical use.
It's painful when it's abused. It is not painful for practical use, and I've written some pretty complex queries in my day.
|
|
|
|
|
Jeremy Falcon wrote: I've written some pretty complex queries
 Me too. And I will do it again if it becomes necessary. But writing big complex SQL queries is no good thing, just because you can!
It's because of maintenance and stable software architecture - especially the impedance mismatch problem in the lifecycle of your business objects - that you greatly profit from if you are using an ORM. I don't want my business logic smeared over different places and written in different languages. I want it in my business domain and nowhere else. And I don't want my business domain polluted with database stuff whatsoever. That is why I prefer an ORM over plain SQL. And if you really need to do something extraordinary (e.g. some performance optimizations) and write a statement yourself, you can do it in the ORM itself.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Sorry, but this post is full of crap. You think SQL sucks because you prefer not having your business logic "smeared" over different places and in different languages. Surely you can see how this is apples and oranges and flawed logic right?
And, you can protect your DB if you don't like it being "smeared".
Regarding ORM, it has its flaws too. It makes the data store way too dependent on the application to work properly. While it's a nice concept, it's far from perfect.
|
|
|
|
|
Jeremy Falcon wrote: Sorry, but this post is full of crap.
It's not. It's just about something you don't agree with. You should choose your words more carefully.
Jeremy Falcon wrote: You think SQL sucks
I don't think so. SQL serves its purpose quite well. I just don't want to have pieces of SQL in the main part of my software. SQL is part of a DB which in turn is part of some persistence system that should help my business logic in doing whatever it's supposed to do. But SQL is not the software itself and thus should be kept apart from the functional pieces of the software - it clearly is an infrastructural service and nothing more. An ORM helps maintaining that separation and prevents you from reinventing the wheel (i.e. writing data access code for every single project) again and again.
Jeremy Falcon wrote: It makes the data store way too dependent on the application
If the data store does not depend on the application, what is it good for then anyway?
Jeremy Falcon wrote: While it's a nice concept, it's far from perfect.
As everything else out there in the wild. Sure, it has its flaws. I never stated and never believed it is perfect. It's not even the preferable solution for every single situation. But in general it's a good one.
Generally, an O/R mapper is not about 'hiding SQL'. You can use SQL freely inside the mapper. There might be people out there who believe that they can avoid learning SQL and use an O/R mapper instead - I'm not one of them.
An O/R mapper is just an advanced conceptional technique that moves data access one step further.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: It's not. It's just about something you don't agree with. You should choose your words more carefully.
You're right, I don't agree with faulty logic.
Thomas Weller wrote: I don't think so. SQL serves its purpose quite well. I just don't want to have pieces of SQL in the main part of my software. SQL is part of a DB which in turn is part of some persistence system that should help my business logic in doing whatever it's supposed to do. But SQL is not the software itself and thus should be kept apart from the functional pieces of the software - it clearly is an infrastructural service and nothing more. An ORM helps maintaining that separation and prevents you from reinventing the wheel (i.e. writing data access code for every single project) again and again.
And no valid reasons outside of prejudice is mentioned.
Thomas Weller wrote: As everything else out there in the wild. Sure, it has its flaws. I never stated and never believed it is perfect. It's not even the preferable solution for every single situation. But in general it's a good one.
And it's still worse than SQL if you care about the design of your application being truly extensible.
Thomas Weller wrote: enerally, an O/R mapper is not about 'hiding SQL'. You can use SQL freely inside the mapper. There might be people out there who believe that they can avoid learning SQL and use an O/R mapper instead - I'm not one of them.
An O/R mapper is just an advanced conceptional technique that moves data access one step further.
But your code doesn't use it and therefore it's pointless to mention this since it's no longer quite as portable.
|
|
|
|
|
This post reads as if we are talking about two completely different things. I don't really get what you mean and it's apparent from your answers that you also don't really realize my points.
That's why I end this pointless discussion here.
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: you also don't really realize my points.
Sorry, but you assume too much. It's pretty straightforward, you say A sucks without giving a real reason why. You say B doesn't suck without giving a real reason why. I say prove A sucks; you don't. I give a disadvantage to B that you don't act as if its important. So, we go 'round and 'round.
|
|
|
|
|
Jeremy Falcon wrote: It's painful when it's abused. It is not painful for practical use
I agree. If there is anything in a query that begins to get too complex, then I usually treat that as an indicator that maybe that part of the database needs to be normalized better.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
True dat. 
|
|
|
|
|
Thomas Weller wrote: In my last project, we wrote an application that was designed to interact with any database whatsoever.
This would be very difficult to achieve but I don't see how a wrapper around SQL (e.g. ET) would solve the problem since the it is only being moved one layer down and it would still have to be solve there.
For multiple SQL server support I tend to use SQL localization. Each supported server type will have it's set of SQL queries. From previous experience, most of the SQL queries are exactly the same and only a few need to be reworked. This approx obviously does not give a solution for "any database whatsoever" but it is usually enough.
Regards.
|
|
|
|
|
PedroMC wrote: I don't see how a wrapper around SQL (e.g. ET) would solve the problem
It indeed does not solve the problem but it makes it much more manageable. Good O/R mappers like NHibernate (not EF!) have support for many DBMS systems. Basically it's just a matter of configuration (there are always some pitfalls, but they are not too painful).
PedroMC wrote: only being moved one layer down
Basically yes. But that's a great big lot for larger business apps!
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
It's not about whether you use SQL or not, it's about whether you decouple the DAL from the rest of the app. Not that the EF helps you with that either, you can easily write code using the EF in the presentation layer!
Marc
|
|
|
|
|
Explicitly using SQL does not prevent decoupling/layering the data access so that is a non issue when comparing EF and explicit SQL usage.
With correct layering the DAL can internally use EF, explicit SQL, or something else to handle the data access.
Regards.
|
|
|
|
|
good call Marc. i am shocked that it took so many posts to get to this.
|
|
|
|
|
Bad pun alert....
When it comes to all these new technologies, I just say EF it. 
|
|
|
|
|
PedroMC wrote: SQL is not the best ever designed language
It's okay, there are worse languages designed.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Definitely not
I don't know what it is
It's not applicable to my work
|
|
|
|
|
I don't use .NET, what should I answer? Not applicable, No idea what it is, or Definitely not? 
|
|
|
|
|
I don't use .NET either, so I didn't know what it was to even choose I don't use .NET. So, I chose I don't know what it is.  It does sound like a buzzword framework though. Maybe I'll write one called the Hype Framework and see if it catches on.
|
|
|
|
|
The client I've been working for uses Linq2SQL. Since it appears to have been slated for a slow painful execution by lack of support, I imagine we might eventually move to EF. The client really likes ORM so if L2S stops meeting their needs we'll move to it. But after looking at the SQL generated by both L2S and EF I don't believe it is performant enough out of the box. And the amount of code required to squeeze good performance out of the SQL doesn't save me any time or code beyond auto-generating my own data access code using CodeSmith or some other templating tool. I would look at it again if there were vendor specific providers (Sql, Oracle) instead of only ANSI SQL. If I could use those providers via an interface (or if they could be swapped out via configuration), then it might be good for small to mid size projects. I don't ever plan on using it for any significant size projects.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
