You should deserialize each transaction (this will take a long initial time), and place transaction data in one NoSQL table (minus vin and vout arrays), harvest the vin and vout data to make a utxo table, and take the addresses and values out of each vout to construct an addresses table.
And of course you can fetch each block, deserialize the data and create a blocks table while you're at it.
SQL databases are horribly inefficient. NoSQLs like MongoDB are better.
You are describing a relational database structure (such as SQL) in a convoluted way.
A NoSQL collection of blocks might break down as follows:
record for block x --> transactions --> list of vIns, each of which references a previously confirmed transaction and index to that transaction and list of vOuts, each of which reference an address and amount.
If a particular vOut is spent, it would be very difficult to lookup that transaction in a NoSQL database.
If you are using a relational database (such as SQL), you can create an
index on any column you are using a WHERE clause on (or are aggregating data on). So if you ever will filter by txid, you can create an index on the txid column in your transactions table. Querying a SQL database when filtering by data in a column that is indexed will be very fast, while querying when filtering by data in a column that is not indexed will be slow (or maybe very slow if your database has many records).
If you need to frequently access data, you can also create a
temporary table. Bitcoin core already does this (or something very similar) by keeping the UTXO set in RAM.
