История изменений

Составные типы в качестве ключа это не самая популярная фича, рано или поздно ты попадёшь в ситуацию где тебе нужно использовать сторонний код или систему где такого нет, а ты уже накатал всё на составных ключах. И будет тебе жопа.

В задаче ТС нет никаких стронних систем, он всё сам контролирует. Налицо пример оверинжиниринга, когда боясь мифического стороннего кода принимают решения, мешающей эффективной реализации.

Кроме того , в случает варианта, предложенного PolarFox (с составными ключами) мы получаем контроль целостности данных на декларативном уровне , а именно - две вершины в ребре всегда будут принадлежать одному графу. Если же не делать составной ключ, то это будет затруднительно.

Да и тебе самому это будет неудобно. Простой пример - как найти последнюю добавленную строку? После добавления это ещё как-то можно, но и то везде по-разному, т.е. костыли. А если не сразу, в другой части системы? Ещё большие костыли. Даже тупо сохранить полученные данные в какой-нибудь хэш-массив по ключу не везде можно, нужно будет городить свой контейнер со своим хэшем и такие затыки на каждом шагу.

Да и тебе самому это будет неудобно. Простой пример - как найти последнюю добавленную строку? После добавления это ещё как-то можно, но и то везде по-разному, т.е. костыли. А если не сразу, в другой части системы? Ещё большие костыли. Даже тупо сохранить полученные данные в какой-нибудь хэш-массив по ключу не везде можно, нужно будет городить свой контейнер со своим хэшем и такие затыки на каждом шагу.

Борьба с неприятностями, которых нет. Еще один пример оверинжиниринга.

Итог с одной стороны имеет удобное копирование, декларативную целостность данных, отсутсвие ненужных уникальных индексов, с другой стороны боязнь непонятно чего и невнятные общие суждения, приводящие к неоптимальным решениям.

Составные типы в качестве ключа это не самая популярная фича, рано или поздно ты попадёшь в ситуацию где тебе нужно использовать сторонний код или систему где такого нет, а ты уже накатал всё на составных ключах. И будет тебе жопа.

В задаче ТС нет никаких стронних систем, он всё сам контролирует. Налицо пример оверинжиниринга, когда боясь мифического стороннего кода принимают решения, мешающей эффективной реализации.

Кроме того , в случает варианта, предложенного PolarFox (с составными ключами) мы получаем контроль целостности данных на декларативном уровне , а именно - две вершины в ребре всегда будут принадлежать одному графу. Если же не делать составной ключ, то это будет затруднительно.

Итог с одной стороны имеет удобное копирование, декларативную целостность данных, отсутсвие ненужных уникальных индексов, с другой стороны боязнь непонятно чего и невнятные общие суждения, приводящие к неоптимальным решениям.