

Removing duplicates in sql, or indexes - not an option - lwcd
http://lukecawood.com/post/15322068310/removing-duplicates-in-sql

======
ericHosick
I am really surprised at the number of developers who have seemingly no
knowledge of Sql.

I've seen very large data-models without any useful indicies and developers
attempting to optimize these systems through manual caching (similar to
indexed views in something like Sql Server).

The trend seems to be worsening and is disconcerting.

Key/value stores are the trend but Sql is still very prevalent and should be
as well understood as something like regular expressions.

~~~
lwcd
Worsening indeed, both with depth of understanding of schema definition and of
query mechanics - very often I see developers run with the first query returns
their desired results, with little regard for performance or understanding how
the results are actually being generated.

------
mzarate06
I understand the point of the article; it's something db developers have been
doing for years. However, I couldn't ignore the following bit about ORMs ...

 _[they're] often removing the need to 'hand write' SQL for anything but the
most complex of query._

I've found that to be false, and that continues to be one reason why I'm
against ORM. For example, the use of unions and aggregates pretty common, yet
the ORMs I've used don't support these things, or at least not w/out having to
fall back to handwritten queries at some point, which only supplements my
point.

I get ORMs, I use them when needed, I'm not entirely religious about being
against them. If the article wants to declare using them as _standard
practice_ , ok. However, I'd find it more accurate if _"removing the need to
'hand write' SQL for anything but the most complex of query"_ was reworded to
_"removing the need to 'hand write' only the simplest of queries."_

~~~
lwcd
Valid point, not all ORMs are created equal.

Django's allows complex queries to be constructed via their Q objects that can
traverse relationships without trouble.

In comparison, the in-house one I am currently provides almost no abstraction
on top of sql.

Striking the right balance between the two is obviously not trivial and can be
a matter of preference.

