Acceptable, perhaps.  But can you name any major RDBMS that uses singular table...

DECLARE @sum INT;

SELECT  @sum = 60 * SUM(CAST(PARSENAME(REPLACE(x, ':', '.'), 2) AS INT)) + SUM(CAST(PARSENAME(REPLACE(x, ':', '.'), 1) AS INT))
FROM    (
 ...

Acceptable, perhaps.  But can you name any major RDBMS that uses singular table names in...

Tables are typically plural.

I don't see why "user" should be in any of these names.

So maybe:

orgs ( orgId int, orgName varchar(100) )

orgTypes ( orgTypeId smallint, orgType varchar(50) )

orgSiteTypes ( orgSiteTypeId...

DROP TABLE IF EXISTS #data;
CREATE TABLE #data ( trip_duration varchar(30) NOT NULL );
INSERT INTO #data VALUES
    ('23:01'), ('00:01'), ('05:15'), ('00:45'), ('00:11');

SELECT 
  ...

 SELECT field, SUBSTRING(field, PATINDEX('%[2][0-9][0-9][0-9]%', field), 4) AS year
 FROM #t

None that I'm aware of.  It's actually an excellent place to store that type of info.

Just be sure you don't drop the table, or you'll lose all the ext props!

;WITH test_data AS (
    SELECT 'A~B~C.ab' AS data
    UNION ALL
    SELECT 'D~E~FG.hij'
)
SELECT data, data_result
FROM test_data
CROSS APPLY (
 ...

You would also want to check what the FK DELETE options are on each table.  For the ones that are CASCADE, that could cause updates in other tables as well...

The way I figured it:

Currently you have 10 files * 100GB reserved = 1000GB.

If you drop each file to 85GB, you'll have 850GB reserved, i.e., 150GB less.  On a drive...

Shrink files 3 thru 8 to, say, 85GB.  Then, wait a while.  Once the tempdb file sizes get more balanced out, shrink files 1 and 2 back to 85GB.  Ultimately...

As for renaming the file, do not use detach; that's an obsolete method.  Instead, issue an ALTER command to change the file name, take the database offline, rename the physical...

Broadly speaking, SQL Server performance comes down to indexes (assuming you don't have major issues with RAM, disk I/O, other basics).

Therefore, first I'd suggest reviewing your indexes for performance.  Unfortunately,...

That code is not valid.  There is no way to tell which 'type' column is being referenced in the WHERE clause.

You have a some options at least to help speed things up.  I'm sure someone can think of others.  (Entries are numbered only to ease possible discussion of them, not...