HackerTrans
TopNewTrendsCommentsPastAskShowJobs

funnymony

no profile record

comments

funnymony
·3 ปีที่แล้ว·discuss
These examples reminded me one more issue: change in column selection, might change number of rows, which means column addition/removal is so much riskier afair.

> Not if distinct is the default.

If that works for you, great, but let’s agree to disagree here.
funnymony
·3 ปีที่แล้ว·discuss
1
funnymony
·3 ปีที่แล้ว·discuss
Performance implication exist, but it is secondary.

Primary reason: distinct on every select shows either lack of knowledge of schema, in particular which columns make rows unique, or unfortunate schema design. (Apart from niche cases, schema should be somewhat normal. I.e. column parent_name belongs in the table parent, not in the table student)

Select a from x where myuniquekey=1; —- guaranted to return 1 or zero rows, if myuiniquekey is actually unique.

Select a from x join y on x.parent_id = y.y_id —- guaranteed to return same amount of rows as exist in y, never more, never duplicates y rows. (N-to-1 relation)

If distinct is used in any of above, then question “why?” naturally arises.

In more severe case, leads to bugs:

Select distinct student.student_name, parent.parent_name from student join parent on student.parent_id = parent.parent_id —- silently discards rows, where by accident student/parent name combo matches several times.

Technically sql allows comparing unrelated columns (colour=last_name), but for vast majority of cases, when joining, one of the side should be joined using it’s unique key, and other side should be using it’s foreign key, which ensures that duplicates don’t appear randomly, and thus distinct is not needed.
funnymony
·3 ปีที่แล้ว·discuss
Its a matter of your eyes being used to this.

If for ten years you always indented the code this way

    Void F()
    {    Foo();
         Bar();
         Baz();}
Then following snippet will seem hard to parse mentally:

    Void F()
    {
         Foo();
         Bar();
         Baz();
    }
And vice versa
funnymony
·3 ปีที่แล้ว·discuss
Somewhat relevant. Estonia has a law that financial instutions should have servers located on Estonian soil. (Exactly for this kind of scenario)
funnymony
·3 ปีที่แล้ว·discuss
Link to exact section: https://dlang.org/spec/function.html#scope-parameters
funnymony
·3 ปีที่แล้ว·discuss
This would be like learning everything from books vs learning by experience. (Can’t learn skiing from books. I talk from experience)
funnymony
·3 ปีที่แล้ว·discuss
> deserialization is validation

I saw similar, catchy phrase: “parse, don’t validate”.

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
funnymony
·3 ปีที่แล้ว·discuss
Interesting idea. But this would require no intermixing between groups.
funnymony
·3 ปีที่แล้ว·discuss
Problem is that despots want power, whatever system you have you will get despots wanting to be at the top, and doing what is necessary to get there. Democracy at least moves them around a bit.
funnymony
·3 ปีที่แล้ว·discuss
I’ve read something like: there are bunch of observations of extremely dense masses in various suroundings. Talented people can find explanations other than black holes in each case. But that feels adhoc, and black hole fits quite nicely for whole class of observations. Current consensus is that b holes exist.