> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Can anybody show me an implementation of a realistic use case that follows >> proper practice — like "every table must a primary key", "a foreign key must >> refer to a primary key", and "joins may be made only "on" columns one of >> which has a PK constraint and the other of which has a FK constraint" — >> where using a not nullable data type brings a problem that wouldn't occur if >> the column were defined with a nullable data type and an explicit "not null" >> constraint? > > Nothing obvious comes to mind. But frankly: > > proper practice includes trying to write idiomatic code for the language you > are using so others familiar with the language can learn your code more > easily. You are violating this to an extreme degree. > > I do not think it to be a good trade-off. SQL writers are practical people > and the idioms largely avoid any downsides that the arise from SQL not being > some paragon of language design. > > -- "\d genres" shows "gk" with a "not null" constraint, whether I write it > -- or not. And convention seems to say "don't clutter you code by writing it". > create table genres( > gk int primary key, > gv text not null > ); > > "Primary Key" is defined to be the application of both UNIQUE and NOT NULL > constraints...
Yes, I know what "primary key" implies. I meant only to emphasize that the source column for what the "outer join" projects has a not null constraint, that it doesn't apply to the projection of that column, that this is perfectly understandable, and that this isn't a problem. Never mind. What part of the code that I showed (the "genres" and "books" use case) violated, to an extreme degree, what you would have wanted me to write—and in what way?
