Как взять id будущей записи?

Question

[ortsuev33]

Есть имя_товара нужно получить id который будет у этой записи в бд при вставке, т.е на сайте у меня будет строка имятовара_id потом строку разобью и получу товар по ид. Мне нужен так сказать будущий id этой записи, и ещё чисто теоретически если запрос длился бы 1мин прт инсерте как бы распределялись id записей Autoincr у обоих записей было бы id одинаковое или сразу сформировалось по очереди,вопрос к тому что может быть когда один инсерт не прошел а идет уже второй

Answer 1

[poniyur]

Если insert долгий, то сделайте сначала просто insert с пустыми данными.
Тогда запрос пройдёт быстро, id будет. Далее используете update.
Тут есть пример на PDO как получить последний вставленный id записи, которую вы и будете update'ить

Answer 2

[Lander]

Для получения следующего значения автоинкрементируемого поля можно использовать запрос:

SELECT `auto_increment` FROM INFORMATION_SCHEMA.TABLES WHERE table_name = 'tablename'

Но как совершенно верно заметил коллега Александр - идея абсолютно идиотская.

Comments

[avmaksimov]

А данный запрос увеличивает инкремент? И можно ли использовать из разных потоков, чтобы на MS SQL повесить задачу сведения в один поток?)

Answer 3

[Александр]

Никак нормально вы не получите id будущей записи. Если вам нужно использовать id - то сначала делается вставка, получается id, а уже потом редактирование с добавление этого id куда вам необходимо.

Answer 4

[LobsterJoe]

Откажитесь от использования автоинкрементного Id.
Я бы использовал вызов вот этой библиотеки в конструкторе объекта для генерации Id. Вероятность коллизий настолько мала, что ей можно пренебречь.

Comments

[Egorr]

Вы использовали этот ramsey/uuid? Идея мне очень нравится.

[LobsterJoe]

Egorr, Да, я активно использую эту библиотеку в связке с Doctrine.

Вот пример сущности, использующей Uuid:

<?php

namespace App\Entity\Article;

use ApiPlatform\Core\Annotation\ApiResource;
use ApiPlatform\Core\Annotation\ApiProperty;
use Doctrine\ORM\Mapping as ORM;
use Ramsey\Uuid\Uuid;

/**
 * Class Block
 * @ApiResource()
 * @ORM\Entity()
 * @ORM\HasLifecycleCallbacks()
 */
class Block
{
    /**
     * @ORM\Id()
     * @ORM\Column(type="guid")
     * @ApiProperty(iri="https://schema.org/identifier", identifier=true)
     */
    protected $id;
    /**
     * @ORM\ManyToOne(targetEntity="App\Entity\Article\Article", inversedBy="blocks")
     * @ORM\JoinColumn(name="articleId", referencedColumnName="id", onDelete="SET NULL")
     **/
    protected $article;

    public function __construct()
    {
        $this->id = Uuid::uuid4();
    }

    /**
     * @return mixed
     */
    public function getId()
    {
        return $this->id;
    }
}

Итого, при создании экземпляра класса мы уже имеем автоматически сгенерированный уникальный Id. Можно также задействовать валидатор и бросить исключение, если вдруг! был сгенерирован уже существующий идентификатор.

[Egorr]

LobsterJoe, Добрый день! Я хочу задать вопрос.
Прочитал несколько статей о применении uuid.
Cделал ради пробы одну модель с uuid.
Но вот в чём сомнения...
Некоторые пишут о низкой производительности выборки с WHERE. Это так?
Очень непривычно видеть строчный id (у меня char(36)). Нет ли вариантов uuid c int?

[LobsterJoe]

Egorr, Ну, если говорить о производительности, то на мой взгляд, это актуально лишь на действительно больших объёмах одновременных операций (например, как описано тут - it takes 20 minutes to insert 100,000 records into a UUID table which already contains 15 million records).

В таких случаях да, вероятно, нужно искать другое решение. Вот вариант с PostgreSQL/Sequence.

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

Answer 5

[Александр Маджугин]

Хотя идея бредовая сама по себе, но я бы решал так - сделал бы в базу запись где все поля пусты, взял бы ее id и исползовал, а когда в будущем бы потребовалось добавить товар с этим его будущем id проапдейтил бы эту запись.

Comments

[avmaksimov]

Не скажите.. Например, сначала надо создать структуру данных, а далее уже добавлять её в БД. При этом, пользователь может отказаться от ввода данных, но если он подтверждает, то данные изменения должны раскатиться через приложение-сервер её клиентам. В вашем случае подтверждение разошлёт пустые некорректные данные.

[Александр Маджугин]

avmaksimov, в моем случае будет дополнительное поле которое будет показывать состояние записи - пустая/готовая/отправленная.

[avmaksimov]

Александр Маджугин, понял, но это доп. фильтр, кроме, например, удалена или нет, а также скрыта или видна). Но идея ясна - спасибо.

Answer 6

[ixon]

С помощью SQL запросите максимальный элемент таблицы в поле id и добавьте к нему 1. Это и будет идентификатор будущей новой записи.
MAX(id)+1

Comments

[Александр]

Во первых никаких гарантий нету, что последнюю запись недавно не удаляли и ваш MAX(id)+1 не вернет id этой записи, вместо id действительно той записи, которая будет создана. А во вторых вы никак не можете забронировать id будущей записи и если между вашим запросом и запросом вставки будет выполнена другая вставка в эту таблицу - тогда возникнет коллизия.

[Папа Стифлера]

За такие советы увольнять по статье о несоответствии.

[ixon]

Александр, если последнюю запись удалили, тогда максимальная запись будет последняя-1. И max(id)+1 вернёт id последней удалённой записи.
Чтобы между запросами вставки не происходило других запросов нужно объединять запросы в транзакции. Но это маловероятно.

[Александр]

ixon,

если последнюю запись удалили, тогда максимальная запись будет последняя-1. И max(id)+1 вернёт id последней удалённой записи.

Объясняю на пальцах: в таблице были записи 7,8,9. Запись с id 9 удалили, максимальная запись имеет id 8, а следующая запись которую добавят будет иметь id 10, потому что id будущей записи зависит от значение свойства auto_increment, а не от того, какой сейчас максимальный id в таблице.

Чтобы между запросами вставки не происходило других запросов нужно объединять запросы в транзакции.

С каких пор транзакции гарантируют атомарность операции? Чтобы между запросами ничего не вставили - нужно блокировать таблицу, но это уже верх глупости.

Но это маловероятно.

Сочувствую вашим заказчикам.

[ponaehal]

Папа Стифлера, Нет, поступая так, Вы подставляете будущего работодателя. Надо пальцы отрубать! :)