Converting SQL Server types and rules to PostgreSQL

In SQL Server, you can use user-defined types to enforce business rules directly on our schema. A custom phone number or email type ensures [music] that every column that uses it has the exact same validation logic. But what happens to those rules when you migrate to Postgres? Let's see how Database Migration Service ensures your data's blueprint remains intact. [music] On the left is a T-SQL statement creating a phone number type. It's based on a varchar and it has a rule attached to check that [music] the format is valid. On the right, DMS has translated this into Postgres. Now, DMS didn't just convert the base type. It created a Postgres domain and most importantly, it brought the check constraint along with it. And why is that so cool? Let's ask Gemini. >> [music] >> A domain is the Postgres equivalent of a user-defined type. It's a standard SQL feature that lets you create a custom data type with its own [music] set of constraints. By converting your user-defined type to a domain, DMS is using the idiomatic Postgres feature [music] to achieve the same goal. This is a huge time-saver. >> [music] >> Imagine having this phone number type used in 10 different tables. DMS migrates the rule once. You don't have to manually add a check constraint to 10 different columns and risk making a mistake. [music] Your data integrity is preserved automatically. This is about more than just moving data. It's about migrating the intelligence and the safeguards you've built into your schema over years of development. DMS understands the blueprint of your database. [music] Migrate your entire schema, rules and all. See how DMS protects your data's integrity and try the conversion workspace today. Check out the links in the description to learn more. >> [music]