Re: Design strategy for table with many attributes

On Fri, Jul 5, 2024 at 10:45 AM Guyren Howe <guyren(at)gmail(dot)com> wrote:

> On Jul 4, 2024, at 22:07, Lok P <loknath(dot)73(at)gmail(dot)com> wrote:
>
> If you stick to the principle of grouping columns in a table when you use
> those columns together, you should be good.
>
> Note that you might want to split up the “parent” table if that naturally
> groups its columns together for certain uses. In that case, you could have
> the same pk on all the 1:1 tables you then have. In that case, the pk for
> each of those tables is also the fk.
>

Thank you.

When you said below,

*"Note that you might want to split up the “parent” table if that naturally
groups its columns together for certain uses. In that case, you could have
the same pk on all the 1:1 tables you then have. In that case, the pk for
each of those tables is also the fk."*
Do you mean having a real FK created through DDL and maintaining it or just
assume it and no need to define it for all the pieces/tables. Only keep the
same PK across all the pieces and as we know these are related to the same
transaction and are logically related?