beginner_dk (3/18/2013)
A: I guess C is a possible answer as the transactions logs are automatically truncated with back up
No they're not.
A: I am guessing B as the answer as "a link between tables" can also be a FK (FOREIGN KEY) and UC are used for FK's
They can be, but they're not required (either of the other 2 unique-guaranteeing structures is fine too). Still, a UQ does not in any way provide a link between tables, so no, B is wrong too.
A: B as it is not mandatory to specify the partition by in over clause
If PARTITION BY is not specified, the function treats all rows of the query result set as a single group.
B does not necessarily provide an ordered resultset. It provides row numbers ordered by the customer name, the resultset however is not necessarily ordered that way. The only one that has an ORDER BY clause (required for guaranteeing an ordered resultset) has a syntax error.
Don't confuse 'will usually work the way you want' with 'is guaranteed to work the way you want'. No order by clause, no guarantee of order.
For B to be correct, it needs ORDER BY CustomerName added at the end.
A: D as coming from SQL SERVER 2008 Full text indexes are stored in databases unlike the previous versions where they are stored on disks structured outside the database
Outside the DB doesn't mean they're not backed up with the DB. Fulltext indexes have always been backed up with the DB, that they're now in the DB files doesn't suddenly change that.
From Books Online (SQL 2005 entry)
Backup and restore treat full-text catalogs the same as database files. If the database that is being copied contains tables that have been defined for full-text indexing, then the destination computer must also have Full-Text Search installed before the full-text catalogs can be re-created and repopulated. If the Microsoft Full-Text Engine for SQL Server (MSFTESQL) service is not installed, the full-text catalog will be offline after restore.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability