Tag Info

New answers tagged

0

When I learned SQL, the INNER JOIN, LEFT JOIN, etc. forms didn't exist. As other answers have already stated, different dialects of SQL had each implemented outer joins using idiosyncratic syntax. This damaged portability of SQL code. Bringing the language back together required some change, and LEFT JOIN, etc. was what they settled on. It's true that ...


1

For the data side of this. You'll have to decide whether to use a relational database? Some other database variants might be more suited. If you choose to use a relational database, you could use the following tables: A table that models the temporal dimension of the activity stream, E.g.: <activity_id, user_id, timestamp> A table containing ...


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 ...


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 ...


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 ...


0

It's not always bad to put queries in loops, but when you can express the "loop logic" in SQL itself, doing it that way is usually more efficient and more readable. In this case, you can easily use a single query with the IN operator (as Robert said), and that expresses what you're actually trying to do much better than a for loop of smaller queries. Both ...


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.


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 ...


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 ...


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 ...


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 ...


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.


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 ...


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 ...


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 ...


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 ...


0

Using the exact same words from @JeffO "Isn't user_id a foreign key?" I think the problem is not necessarilly setting a foreign key or not. The problem is how much do you need to depend on the database features. On Laravel you will set your foreign keys while addinf your migrations: http://laravel.com/docs/4.2/schema#foreign-keys But if you for any ...



Top 50 recent answers are included