You are correct when saying that Materialized View's logic can be implemented using a regular Delta table (outside of SDP). What Materialized Views bring you:
Automatic lineage: with regular Delta table you have to provide dependencies manually through tasks in a Workflow. In SDP this is done automatically;
If run on Serverless SDP: the updates on the Materialized View are incremental. For instance, if you have a regular Delta table:
CREATE OR REPLACE TABLE tx_customers AS
SELECT * FROM transactions t
LEFT JOIN customers c on t.customer_id = c.customer_id
If there is a new row appended to the transactions table, running this will recalculate the join for all transactions, even if we want to update only one. An equivalent Materialized View on Serverless SDP:
CREATE OR REPLACE MATERIALIZED VIEW tx_customers AS
SELECT * FROM transactions t
LEFT JOIN customers c on t.customer_id = c.customer_id
will update / insert only that one transaction. It will handle all the complex logic of incremental updates under the hood so you don't have to do it yourself.
A @dp.table will always result in a Materialized View.
As a side note, a Materialized View is actually backed by Delta as well, but it has these extra features listed above.
