What are the best practices in tSQlt?

Question

Database

The task is to write unit tests for a database on MSSQL Server with 1500 stored procedures and about 600 tables in the database. The base was written and maintained by several developers for about 12 years, and now also continues to change periodically.
I chose tSQLt - tsqlt.org/ as my testing tool.
1. What practical benefit can such unit testing bring.
What immediately comes to mind is in a situation where each HP is covered with at least one positive test, then in the case when several HPs depend on one database table, and the database developer changes the structure of this table, then changes, say, the code of one of the HPs, and forgets about the other HPs that depend on the table, then our test cases are expected to fail on these HPs, thereby signaling to the developer that his attention is required here. In short, it turns out regression testing.
Can there be any other benefit from such unit testing?
2. Распространенная практика в тест-дизайне - искать граничные точки и писать для них тесты. Но представим себе несколько таблиц, которые соединяются джойнами, пусть даже всего 3. Сколько тест-кейсов можно составить, то есть сколько различных вариантов может быть - когда одна таблица пуста, 2 другие содержат записи, или наоборот? Комбинаторика подсказывает нам, что такое число будет вычисляться по формуле факториала. А еще в ХП есть куча разных условий на сравнение с определенным значением, то это число еще возрастает.
Т.е. разумным представляется писать по одному тесту на одну ХП, в котором будет проверяться, что ожидаемый результат теста будет равен возвращенному ХП. Тем более, что повторюсь, мне охватить надо, до 1500 ХП.
Какие в данном случае могут быть best practices? Такой подход имеет право на жизнь?