Tag Info

Hot answers tagged

38

There are only two good reasons to report something like this to management: is if you believe that the coder who did this was malicious and attempting to sneak something through, or if you believe that the coder who did this is incompetent, which can be just as harmful as a malicious coder. From the way you describe him, it sounds like you believe he's ...


34

This is the whole point of code review. Mistake is written. Mistake is found and corrected in code review. Do you want to tattle on your senior team member? This team member according to you has never made a similar mistake before. Unless the code was intentionally written that way (and you can prove it) this is a really dumb idea to go to management ...


22

With the author's approach, teaching OUTER JOINs is going to much more difficult. The ON clause in INNER JOIN was never mind-blowing to me like a lot of other stuff. Maybe it is because I never learned the old way. I'd like to think there is a reason we got rid of it and it wasn't to be smug and call this method low class. It's true in the very narrow ...


12

Whether it's slower depends on the Query Optimizer and how it streamlines the query (what you write isn't actually what is executed). However, the big problem with this quote is that it completely ignores the fact that there are different types of joins which operate completely differently. For instance, what is being said is (theoretically) true for inner ...


9

The author presents a simple case where either the old or new syntax can be used. I do not agree on his/her statement that joins are insanely confusing, because joining tables is a fundamental SQL query concept. So, maybe the author should have spent some time prior in explaining how JOINS work before uttering an opinionated statement as well as doing a ...


8

You can use an IN clause for this. SELECT someFields FROM yourDictionaryTable WHERE key IN (List of values) You'll need to build your list of values as a string with single quotes and commas, like this: 'value1', 'value2', 'value3' This will give you a single, high-performing SQL query which will return the data set you want.


5

There shouldn't be, the query parser should generate an equivalent internal representation for equivalent queries regardless of how they're written. The author's just using pre-SQL-92 syntax, which is why he mentions it might be seen as "old fashioned" or "low class". Internally, the parser and optimizer should generate the same query plan.


5

I learned SQL this way, including the *= syntax for outer joins. To me, it was very intuitive since all relations were given equal precedence and did a better job of setting up queries as a series of questions: What do you want? Where do you want them from? Which ones do you want? By doing join syntax, it disrupts the thought process towards the relations ...


4

There are two different aspects of this to consider: Performance and Maintainability/Readability. Maintainability/Readability I chose a different query, as it is something that I think is a better/worse example than the original query that you posted. What looks better to you and is more readable? select e.LoginID, DepartmentName = d.Name from ...


3

No, it's not true at all. The author is setting up his readers for confusion, and encouraging cargo-cult programming that avoids a very powerful structural difference between the standard syntax and this older variant he prefers. Specifically, a cluttered WHERE clause makes it harder to figure out what makes his query special. His example leads a reader ...


3

Guy is making a classic error. He's trying to teach an abstract concept with a specific implementation. As soon as you do that you get into this sort of mess. Should have taught basic database concepts first, then shown SQL as one way of describing them. Left and right joins, could be argued they don't matter too much. Outer Join, well you could use the ...


2

The example is equivalent to the simple reformulation with inner JOINs. The difference lies solely in the additional possibilities that the JOIN syntax allows. For instance, you can specify the order in which the columns of the two tables involved are processed; see e.g. http://stackoverflow.com/a/1018825/259310. The received wisdom is, when in doubt, to ...


2

As a person who has had to fix timezone issues, ALWAYS store the data in UTC. Translate it to the timezone they selected for display only. If SQL Server allows you to store the UTC offset as part of the datetime, then it's not as big of a deal. However, in MySQL, the date is just stored absent of timezone context. Here's a case in point, which I hope I can ...


1

Yes it is, because if you have thousands of records then it will execute thousands of queries which will be heavy on the database. There are 2 approaches I can think of to avoid this, Use in statement as mentioned by Robert Harvey One consideration is there is a limit in parameters that can be passed into IN clause in depending on the database. So If ...


1

If you are using SQL Server 2008 or higher, I recommend the DATETIMEOFFSET data type. It stores exactly what you want: date + time + time zone offset. This means that you don't have to write code to translate the value to/from UTC. It also means that no one can forget to translate the value to/from UTC and corrupt the data. PS: This data type translates ...


1

There are many node libraries specially made for this. You could try ORM solutions like SequelizeJS http://sequelizejs.com/ or in your case I think Knex http://knexjs.org/ would be better.



Only top voted, non community-wiki answers of a minimum length are eligible