Exam Professional Data Engineer topic 1 question 24 discussion

"E" looks better. For D, the database will be double in size (which increases the storage price) and the user has to spend some more days reloading all the data.

E - more simple and reasonable. Also recommended if not concerned about cost but simplicity. https://cloud.google.com/bigquery/docs/manually-changing-schemas#changing_a_columns_data_type

Changing DT to TIMESTAMP. Create a view casting the string. Answer C.

I was hesitating between C and E, but E seems to be the good one

Both options C (creating a view) and E (creating a new table) avoid reloading the original data. However, C is the better choice for minimizing effort and maintaining performance. Views don't store any data themselves. They simply act as a layer on top of the existing table. This means you avoid the cost of storing duplicate data, which can be significant for large tables.

Create a view no data migration easy to do but computational efficient queries not sure (?)

E. It recreates the table one time and everything is fixed. Next time you load, load to the new table, you can delete the previous one. Definitely not C. The question says I have to minimize future query effort, which literally means "don't create a view that converts from STR to TIMESTAMP for every row."

Option E is correct. The question is asking to consider the Query cost for future. This is a one time job to fix the Timestamp column. no views were created.

Why Option E is the best choice: It modifies the schema with minimal data movement. The original table remains untouched for potential future needs. Future data loads can directly go to the new table with the desired schema. Queries referencing the new table (NEW_CLICK_STREAM) will benefit from the optimized data type for timestamp operations.

minimizing effort is key.

A view in Google BigQuery is a virtual table defined by a SQL query. By creating a view that casts the DT column as a TIMESTAMP, you can transform the data format without altering the underlying data in the CLICK_STREAM table. This means you don't have to reload any data, thereby minimizing migration effort.

Good point about the logical views and the desire to reduce costs. I would vote for E

The best way to minimize the migration effort without making future queries computationally expensive is to create a view and reference it instead of the table. This is because views are materialized when they are queried, so they do not incur any additional overhead. So the answer is (C).

Option "E" It avoids the need to delete and recreate the entire CLICK_STREAM table, which is time-consuming and requires reloading all data. It allows you to use a simple query to cast the existing DT column as TIMESTAMP values and store the results in a new table, NEW_CLICK_STREAM. You can gradually migrate to the new data format, and your future queries will be able to utilize the TIMESTAMP data type for more efficient processing.

Option D duplicates, not a good solution

E. E. You can use a special command to change the time on the old cards to the better type "TIMESTAMP" and create a new box called "NEW_CLICK_STREAM." From now on, you'll look at the new box whenever you want to know the time. It's like having a new and better box to keep things tidy and organized. So, the best way to change the time on the little cards to the better type "TIMESTAMP" is option E. It's like using magic to create a new box and making sure everything is still easy to find and work with. It's a clever way to keep track of time and make your website even better!

they asked to "change its data type"