Something like this might do the trick (untested as I don't have any table structures or sample data!).
UPDATE table_a a
SET a.firstCreationTime = c.f_ca
SELECT b_id, f_ca FROM
b.id AS b_id,
b.created_at AS f_ca,
ROW_NUMBER() OVER (PARTITION BY b.id
ORDER BY b.id, b.created_at ASC) AS ...
I think what you are searching for is
CREATE TABLE table_a ("id" int , "firstCreationTime" timestamp)
INSERT INTO table_a VALUES (1,CURRENT_TIMESTAMP - INTERVAL '1 days')
CREATE TABLE table_b ("id" int , "created_at" timestamp)
INSERT INTO table_b VALUES (1,CURRENT_TIMESTAMP - INTERVAL '10 days')
I think this might be the answer and might help others with this problem.
I had a test trigger on the table member
CREATE TRIGGER `test` BEFORE UPDATE ON `member` FOR EACH ROW
DECLARE addr VARCHAR(100);
DECLARE joint INT;
SET @joint := is_joint_member(member.member_id);
SET @addr = 'jgkjgkjg' ;
CALL dummy2; ...
This is a little close to an opinionated question, but in general, I think you'll find option a to be the mostly widely used one from the perspective of the database layer. For the purpose of this answer, I'm using the term enum as synonymous with lookup table, for all intents and purposes.
Enums are inherently meant to numerically give meaning to a concept ...
Wouldn't it be simpler / easier to just choose a random number who's range is outside your current range of values in the member table? E.g. something like (FLOOR(RAND(id)) * -1) + (SELECT MIN(id) FROM member) (semi-pseudocode)?