The code looks like this:
paramText db "this is text", 0
db is "define byte" and this code will produce these bytes (in hexadecimal formatting):
74 68 69 73 20 69 73 20 74 65 78 74 00
The "string" in quotes is split into ASCII character codes (UTF8 in NASM is possible too I believe, so then one character may produce multiple bytes) for individual characters, and the last value ", 0" is just compiled as that, as zero.
db 1, 2, 3 would produce 3 machine code bytes
01 02 03.
The zero is put after last letter as "string nul terminator" for the use by other code, which accepts strings terminated by zero (like
The "variable" is quite high level concept in programming, and the machine doesn't directly support it, what you get at compile time is "symbol/symbolic name"
paramText, which equals to the memory address of first byte defined after it (that
0x74) = this can be used at compile time to work with that address. Then the
db produces actual binary machine code = which will exist at runtime, as values loaded into memory by OS. And the last zero is part of the "variable content" in this context (not "after" it), if you want to think about it like that.
But it's just binary values in computer memory. The "variable" logic (including the type and/or formatting) is created by the code, which manipulates with memory, and by the programming language + compiler, allowing such constructs in the source code, but CPU itself is not aware of that concept, and it operates only with bits (usually grouped into bytes, words, ...).
EDIT: you can actually use C-like string escaped values in NASM too, but the string must be enclosed in backticks, like:
paramText: db `this is text/0`
Quotes and apostrophes don't scan the string literal for escape sequence, and would compile "/0" as two characters. But using ", 0" as next byte definition is IMO easier to remember, than to remember the difference between backtick/quote defined strings which is NASM-specific feature, not supported by all x86 assemblers.