I assume our near-future strategy is letting AI do a lot of work. Checking more contextual issues than technical ones. LinkedIn is crowded by "AI Agents" (to be honest, most of them are not agents, just simple processes, but that's another discussion), so dealing with real AI Agents, using a RAG approach with further domain-specific knowledge in the form of documents, wikis, structured data, ... Alternative ideas: - Implement an electrical shocker for business people entering the garbage. - Place at least 4 confirmation buttons after each single input field. - Blame the "garbage of the month" team. 🤪

Rephrase "Data Vault is dead!" to: "Materializing a Raw Vault dies but lives now in the Data Catalog and automated querying/processing!"

Hi from my side, too. We had that discussion in my CDV2P Bootcamp today. "Adding new keys" is changing granularity. If it's due to schema evolution or absorbing new sources, different keys or different amounts of keys -> separate links. Sometimes, having the same link elements, there may be a reason, too, to separate: Different driving keys in different source tables with identical keys is also a reason to separate. I hope that helps and supplements @Marc Winkelmann 's statement.

If the hashing Algorithm is known, there is nearly no protection. Day of birth is about 100 (yrs) x 365 (days) values possible. Generating a 365k rows lookup table is a no-cost no-brainer. Same for city, zip code, social security number and more PII attributes. Or am I wrong with these assumptions?

I‘d take the red pill and start implementing DV in the underground.