Tar_As,
for MySQL

s_ustinovskyANAпропущено...

Так ведь речь про MySQL, там Sequence через AUTO_INCREMENT
Блин, я почему-то подумал, что оракл.

Даже если бы там был 300 раз Оракел этоже полный ппц по дизайну. В оракле поле id никак не защищено, т.к. это не автоинкремент и программеры могут залить туда любой мусор. Откуда программеры знают, какую сиквенс дергать, ведь они никак не привязаны к таблицам? Поэтому во вменяемом дизайне никtо даже права на сиквенсы не выдаёт. Второе, на поле id почти всегда есть триггер, в котором и обязано генерироваться id, и какое он там сгенерит значение - большой вопрос. insert ... returning into ... наше все. За приведенный вами метод заполнения id нужно бить линейкой по рукам, уж извините.

Cane Cat FisherTar_As


этот вариант есть и существует, но не влезет ли между ними другой insert от другого вопрошающего без транзакции?

Нет, не влезет. Ибо сказано:

MySQL 8.0 Reference ManualThe ID that was generated is maintained in the server on a per-connection basis. This means that the value returned by the function to a given client is the first AUTO_INCREMENT value generated for most recent statement affecting an AUTO_INCREMENT column by that client. This value cannot be affected by other clients, even if they generate AUTO_INCREMENT values of their own. This behavior ensures that each client can retrieve its own ID without concern for the activity of other clients, and without the need for locks or transactions.

Правда, надо учитывать:

Is MySql's LAST_INSERT_ID() function guaranteed to be correct?A couple caveats I'd like to point out when using LAST_INSERT_ID:

I know you mentioned single-row inserts. But when doing multiple-row inserts, LAST_INSERT_ID() will return the value of the first row inserted (not the last).

If the insert failed, LAST_INSERT_ID() would be undefined. The same is true for automatic rollbacks of transactions (due to errors).

If you do an insert in a transaction that succeeds, and you still issue a ROLLBACK, LAST_INSERT_ID() would be left as it was prior to the rollback.

There are a couple caveats when using AUTO_INCREMENT and LAST_INSERT_ID in statement-based replication. The first being when used in a trigger or function. The second being the less-common scenario where your auto_increment column is part of a composite primary key and is not the first column in the key.



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

s_ustinovRelic Hunterпропущено...


Даже если бы там был 300 раз Оракел этоже полный ппц по дизайну. В оракле поле id никак не защищено, т.к. это не автоинкремент и программеры могут залить туда любой мусор. Откуда программеры знают, какую сиквенс дергать, ведь они никак не привязаны к таблицам? Поэтому во вменяемом дизайне никtо даже права на сиквенсы не выдаёт. Второе, на поле id почти всегда есть триггер, в котором и обязано генерироваться id, и какое он там сгенерит значение - большой вопрос. insert ... returning into ... наше все. За приведенный вами метод заполнения id нужно бить линейкой по рукам, уж извините.
То есть разработчики СУБД, специально создавшие сиквенсы именно для таких целей - идиоты, а вы крутой спец, знающий про правильный дизайн. :))
А уж про программистов, не знающих "какую сиквенс дергать, ведь они никак не привязаны к таблицам" - это вообще зашибись аргумент.

А где я говорил про разработчиков СУБД, например? Я говорил, что конечным пользователям на сиквенсы прав выдавать нельзя. Накосячат с именами в коде так, что админа отправят на принудительное психиатрическое лечение. Сиквенсы нужно прятать в триггеры. Это многолетняя практика, мэн. Но вам можно делать и по-своему, как говорится "приятного хождения по граблям". )) Я в своей роте такого не допускал.