Removing duplicates in sql, or indexes - not an option
lukecawood.com
Removing duplicates in sql, or indexes - not an option
1–6 of 6 posts
Re: Removing duplicates in sql, or indexes - not an option
#2I 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.
Re: Removing duplicates in sql, or indexes - not an option
#3I 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."
Re: Removing duplicates in sql, or indexes - not an option
#4I 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 wel…
Agreed; the same can be said for other fundamentals such as foreign key constraints. I still see modern day apps being developed where foreign keys, and uniqueness, are only implemented in the application. I understand some protection should be added in the app to prevent errors, but to avoid implementing these constraints in the database itself still leaves the door open for problems to occur.
Re: Removing duplicates in sql, or indexes - not an option
#5I 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 us…
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.
Re: Removing duplicates in sql, or indexes - not an option
#6I 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 wel…
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.