141–150 of 493 posts
If anything this is the problem with industry, articles like this that make vast generalizations from a specific instance, unsubstantiated finger-pointing gestures, and passive aggressively blame the industry as a whole.
IMO she’s still pretty clueless (sorry!), but over the years got better at self-promotion So the real lesson is to be very careful as to who you listen to
She has never been "clueless" and has written insightfully for years.
This post is bizarre, precisely because there is nothing particularly wrong about the original schema, and the author seems to believe that the problem is that the column values were stored as strings, or that the schema wasn't in "third normal form". Which is nonsense. The problem with the original DB design is that the appropriate columns weren't indexed. I don't know enough about the problem space to really know i…
I think if anything, all of it could've been put into a single indexed column since the query was AND ... AND ... not OR. So you could've had a indexed column of "fingerprint", like ip1_blahblah_evil@spammer.somewhere_victim1@our.domain And indexed this, with only single WHERE in the query. I don't understand at all how multiple tables thing would help compared to indices, and the whole post seemed kind of crazy to m…
foo@example.com other@example.net foo@example.co mother@example.net
Btw, storing just the domains, or inverting the email strings, would have speed up the comparison
One of the most useful lessons I ever learned about designing database schemas was the utter uselessness of indexing and searching on datetime fields. Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at all. It was a revelation to me when I decided to experiment with having a indexed date-ONLY field and using th…
Furthermore, often times your query will have an "ORDER BY dateTimeCol" value on it (or, more commonly, ORDER BY dateTimeCol DESC). If your index is created correctly, it means it can return rows with a quick index scan instead of needing to implement a sort as part of the execution plan.
RTFD! (Read The F**in Docs!) - I only skimmed the post, but its definitely something that would have been avoided had some SQL documentation or introduction been read.
I'd argue one of the huge things that differentiates "senior" developers from all the "other" levels - we're not smarter or more more clever than anyone else - we read up on the tools we use, see how they work, read how others have used them before... I understand this was from 2002, but MySQL came out in 1995 - there was certainly at least a handful of books on the topic.
Perhaps when just starting off as an intern, you may be able to argue that you are 'operating in a vacuum' but any number of introductory SQL books or documentation could quickly reveal solutions to the problem encountered in the post. (Some of which are suggested in these comments).
Of course we all make mistakes in software - I definitely could see myself creating such a schema and forgetting to add any sort of indexing - but when running into performance issues later, the only way you'll be able to know what to do next to fix it is by having read literature about details of the tools you are using.
Operating in a vacuum? Then break out of it and inform yourself. Many people have spent many hours creating good documentation and tutorial on many many software tools - use them.
This post is bizarre, precisely because there is nothing particularly wrong about the original schema, and the author seems to believe that the problem is that the column values were stored as strings, or that the schema wasn't in "third normal form". Which is nonsense. The problem with the original DB design is that the appropriate columns weren't indexed. I don't know enough about the problem space to really know i…
One of the most useful lessons I ever learned about designing database schemas was the utter uselessness of indexing and searching on datetime fields. Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at all. It was a revelation to me when I decided to experiment with having a indexed date-ONLY field and using th…
The whole point is that indexes (can) prevent full table scans, which are expensive. This is true even if the column(s) you're indexing have high cardinality: but it relies on performant table or index joins (which, if your rdbms is configured with sufficient memory, should be the case).
I'd really love to be snarky here but I'll try to be polite: all those comments about the example situation are missing the whole point of the post. And it really worries me that there is a good chunk of the tech workers that just ignores the real meaning of something and just nitpick about stupid implementation details. The post is about managing rookie errors, being empathetic and also warn the ageism that pervades…
I don't buy it. If the only point was managing rookie errors, etc., the blog post shouldn't have been 15~ paragraphs of technical discussion and 2 paragraphs at the bottom of "my point is ..." You can't advocate that people just ignore 80% of the article because they're "not the point of the post." I'm sure a good chunk of tech workers are worried that when an influential blogger writes something like this a couple h…
And hey, what's so bad about people learning about 3NF? Are you not supposed to know what that is until you're some mythical ninth level DBA?
One of the most useful lessons I ever learned about designing database schemas was the utter uselessness of indexing and searching on datetime fields. Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at all. It was a revelation to me when I decided to experiment with having a indexed date-ONLY field and using th…
This entirely depends on what kind of index is used. A sorted index, such as a B or B+ tree (used in many SQL databases), will allow for fast point/range lookups in a continuous value space. A typical inverted index or hash based index only allows point lookups of specific values in a discrete value space.