Как избежать явного первичного ключа?

Question

[Игорь]

Мой вопрос заключается в том, как избежать явного первичного ключа.

Сущность ContactHistory очень быстро будет наполняться и есть вероятность что индекс иссякнет (я утрирую)
Я просто хочу сэкономить, зачем использовать явный первичный ключ если он не когда не будет использоваться

Да, можно использовать составной первичный ключ, но я не вижу полей которые гарантировали бы уникальность.

/**
 * @ORM\Entity(repositoryClass=ContactRepository::class)
 * @ORM\Table(name="contacts")
 */
class Contact
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="bigint")
     */
    private ?int $id;

    ...

    /**
     * @var ArrayCollection|PersistentCollection
     * @ORM\OneToMany(targetEntity="ContactHistory", mappedBy="contact", cascade={"remove"}, fetch="EXTRA_LAZY")
     */
    private $history;
    ...
}



/**
 * @ORM\Entity(repositoryClass=ContactHistoryRepository::class)
 * @ORM\Table(name="contacts_history")
 */
class ContactHistory
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="bigint")
     */
    private int $id;

    /**
     * @var Contact|null
     * @ORM\ManyToOne(targetEntity="Contact", inversedBy="history", cascade={"persist"})
     */
    private ?Contact $contact;
    ...
}

Comments

[eRKa]

Первичный ключ не является обязательным в таблице, но как Вы будете делать поиск по таблице? Вы всегда будете выбирать все записи? Еще, обычно, для первичного ключа строится кластерный индекс, поэтому сущности обычно и делают сразу с id и поиск делают по нему. Вы говорите, что таблица быстро наполнится, в этом случае можно использовать гуид, а не биг инт.

[Игорь]

eRKa,

Первичный ключ не является обязательным в таблице

Для Doctrine обязательный.

В таблице contacts_history есть внешний ключ для contact_id.

Если Guid то функцию генерации нужно брать на себя, ведь так?

Answer 1

[Игорь]

Сделал по данной статье

Пока так, исключительно для того что бы доктрина успокоилась

Answer 2

[alexalexes]

Можно сделать локальный id истории, уникальный в пределах одного контакта.
Получается, будет уникальный id контакта + id истории. Вы емкость одного идентификатора размажете на два.
Сортировать можно, находить нужную запись истории можно. Какая запись истории появилась раньше у соседних контактов - скорее всего нельзя выяснить, если нет сквозного id.
На первый взгляд такие возможности и недостатки.

Comments

[Игорь]

alexalexes, что вы имеете в виду когда говорите?

Можно сделать локальный id истории

Взять на себя генерацию уникального ID?

[alexalexes]

Я теоретически рассуждаю. Если у СУБД не будет штатного механизма, то можно написать триггер на вставку локального id. На практике так формируют порядковые номера части записей, отличные от идентификаторов.

[Игорь]

alexalexes, Триггеры не будем использовать, нужно сохранить кросс СУБД.
Да и не слышал я про триггеры в Doctrine

[Игорь]

Можно было бы обойтись без явного первичного ключа, но это противоречит правилам Doctrine ORM

[alexalexes]

Кажется, мой совет вам не подойдет.
Я рассматривал структуру, чтобы можно было выживать на чистых sql запросах.
С Doctrine ORM не знаком.