Check out the solution in the video TSQL: Get Maximum Length of Every Column On A Table. This can be helpful if we require strict limits in downstream tables, assuming that we have a data flow where we initially want to extract data from one set of tables (or table) to another set of tables. On the initial part of any data acceptance, I tend to prefer flexible development.
Where this may be useful:
For mastering data transformation from one form to another form, check out the highest-rated Automating ETL course on Udemy. For a coupon to the course, check out the trailer video on the channel SQL In Six Minutes.
We should be careful about allowing anything, however. This could open us to a security breach, so we still want to qualify data on entry or input. Hackers will test any free form where anything is allowed and for good reason: if developers accept anything, this can be exploited.
One regular point I like to remind my audience, especially as of recent: we can often solve the same problem with a variety of techniques. While we look at one or two ways to solve the problem, these aren't the only ways we can approach this problem. The most appropriate solution to a problem is one in which you can troubleshoot quickly in the future and one in which you understand. Be careful about applying solutions that solve a problem, but introduce new problems in the future.
A great re-occuring example of this is my discussion on alerting best practices. There are a variety of alerts everywhere for everything in today's development environments, but many of these alerts cause more issues than they solve (one of which is creating a distraction). Be careful about "easy" solutions which introduce bigger problems. Know your environment and where to apply the best solution. Of course, all these being written, it is helpful to learn new techniques to solve problems because they may be useful in the future.
SQL In Six | Automating ETL | T-SQL In 2 Hours | Consumer Guide To Digital Security
