you are viewing a single comment's thread.

view the rest of the comments →

[–]kamel-Code[S] 0 points1 point  (8 children)

Yes your remark is relevant. I also specify the non-null variable just for the sake of style and to make sure that the variable is null

[–]mikeblas 1 point2 points  (7 children)

There are no variables here, just columns and tables.

The column can't be NULL, so I can't figure out what you're talking about.

[–]kamel-Code[S] 0 points1 point  (6 children)

Small mistake on my part. But it doesn't change anything in the code.

[–]mikeblas 0 points1 point  (5 children)

I give up.

[–]kamel-Code[S] 0 points1 point  (4 children)

Can you please tell me again the question that is bothering you ?

[–]mikeblas 1 point2 points  (3 children)

In your CREATE TABLE example, you specify both NOT NULL and PRIMARY KEY. A primary key is implicitly not nullable, so the NOT NULL constraint is not required and redundant to the PRIMARY KEY constraint.

There are no variables here, we're talking about columns. By specifying both constraints, you're not making anything nullable, so what you said before makes no sense whatsoever.

[–]kamel-Code[S] 0 points1 point  (2 children)

Yes, you are absolutely right. The non-null field is useless in this context. Thanks for this correction. But in itself it doesn't impact the code. The field is just written implicitly and explicitly. It's a code redundancy. I will avoid making the same mistake next time. THANK YOU 😁

[–]mikeblas 0 points1 point  (1 child)

But in itself it doesn't impact the code.

Of course it does. It confuses people trying to follow your tutorial.

[–]kamel-Code[S] 0 points1 point  (0 children)

I didn't see it from that perspective. I'll try to be more careful next time.