Skip to main content
added 18 characters in body
Source Link
Colin 't Hart
  • 9.4k
  • 15
  • 36
  • 44

For a logical database design you don’t need to specify TINYINT or CHAR — that’s a physical consideration. Some DBMSes such as Postgres have a BOOLEAN data-type which would be preferred, but again, a physical design.

In your logical model you could assume a binary-valued datatype with Yes and No as the two values (or a ternary-valued type if NULL should also be allowed).

You have two questions actually; for the other, yes, I would keep the flag in the same relation.

For a logical database design you don’t need to specify TINYINT or CHAR — that’s a physical consideration. Some DBMSes such as Postgres have a BOOLEAN data-type which would be preferred, but again, a physical design.

In your logical model you could assume a binary datatype with Yes and No as the two values (or a ternary type if NULL should also be allowed).

You have two questions actually; for the other, yes, I would keep the flag in the same relation.

For a logical database design you don’t need to specify TINYINT or CHAR — that’s a physical consideration. Some DBMSes such as Postgres have a BOOLEAN data-type which would be preferred, but again, a physical design.

In your logical model you could assume a binary-valued datatype with Yes and No as the two values (or a ternary-valued type if NULL should also be allowed).

You have two questions actually; for the other, yes, I would keep the flag in the same relation.

Source Link
Colin 't Hart
  • 9.4k
  • 15
  • 36
  • 44

For a logical database design you don’t need to specify TINYINT or CHAR — that’s a physical consideration. Some DBMSes such as Postgres have a BOOLEAN data-type which would be preferred, but again, a physical design.

In your logical model you could assume a binary datatype with Yes and No as the two values (or a ternary type if NULL should also be allowed).

You have two questions actually; for the other, yes, I would keep the flag in the same relation.