Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
One could either do a unique constraint on those foreign keys or a composite primary key on those columns. For elegance, canonicity, a primary key is necessary. You would initially have a primary...
Answer
#3: Post edited
by
. .
·
2020-08-24T19:14:41Z (over 4 years ago)
clarifies
- > One could either do a unique constraint on those foreign keys or a composite primary key on those columns.
- For elegance, canonicity, a primary key is necessary. You would initially have a primary key on those columns.
However, for sortability reasons, you would eventually use just a primary key on a single column, so no, in the end you don't have a primary key on those columns, but a unique constraint.
- > One could either do a unique constraint on those foreign keys or a composite primary key on those columns.
- For elegance, canonicity, a primary key is necessary. You would initially have a primary key on those columns.
- However, for sortability reasons, you would eventually use just a primary key on a single column ad-hoc created to be the id/key, so no, in the end you don't have a primary key on those columns, but a unique constraint.
#2: Post edited
by
. .
·
2020-08-24T00:50:28Z (over 4 years ago)
- > One could either do a unique constraint on those foreign keys or a composite primary key on those columns.
- For elegance, canonicity, a primary key is necessary. You would initially have a primary key on those columns.
However, for sortability reasons, you would eventually use just a primary key on a single column, so no, you don't have a primary key on those columns, but a unique constraint.
- > One could either do a unique constraint on those foreign keys or a composite primary key on those columns.
- For elegance, canonicity, a primary key is necessary. You would initially have a primary key on those columns.
- However, for sortability reasons, you would eventually use just a primary key on a single column, so no, in the end you don't have a primary key on those columns, but a unique constraint.
#1: Initial revision
by
. .
·
2020-08-24T00:49:43Z (over 4 years ago)
> One could either do a unique constraint on those foreign keys or a composite primary key on those columns. For elegance, canonicity, a primary key is necessary. You would initially have a primary key on those columns. However, for sortability reasons, you would eventually use just a primary key on a single column, so no, you don't have a primary key on those columns, but a unique constraint.