###BeginCaseStudy###
Case Study: 1
Scenario 1
Application Information
Your company receives invoices in XML format from customers. Currently, the invoices are
stored as files and processed by a desktop application. The application has several
performance and security issues. The application is being migrated to a SQL Server-based
solution. A schema named InvoiceSchema has been created for the invoices xml.
The data in the invoices is sometimes incomplete. The incomplete data must be stored and
processed as-is. Users cannot filter the data provided through views.
You are designing a SQL Server database named DB1 that will be used to receive, process,
and securely store the invoice data. A third-party Microsoft .NET Framework component will
be purchased to perform tax calculations. The third-party tax component will be provided as a
DLL file named Treytax.dll and a source code file named Amortize.cs. The component will
expose a class named TreyResearch and a method named Amortize(). The files are located in
c:\temp\.
The following graphic shows the planned tables:
You have a sequence named Accounting.InvoiceID_Seq.
You plan to create two certificates named CERT1 and CERT2. You will create CERT1 in
master. You will create CERT2 in DB1.
You have a legacy application that requires the ability to generate dynamic T-SQL statements
against DB1. A sample of the queries generated by the legacy application appears in
Legacy.sql.
Application Requirements
The planned database has the following requirements:
• All stored procedures must be signed.
• The original XML invoices must be stored in the database.
• An XML schema must be used to validate the invoice data.
• Dynamic T-SQL statements must be converted to stored procedures.
• Access to the .NET Framework tax components must be available to T-SQL objects.
• Columns must be defined by using data types that minimize the amount of space used
by each table.
• Invoices stored in the InvoiceStatus table must refer to an invoice by the same
identifier used by the Invoice table.
• To protect against the theft of backup disks, invoice data must be protected by using
the highest level of encryption.
• The solution must provide a table-valued function that provides users with the ability
to filter invoices by customer.
• Indexes must be optimized periodically based on their fragmentation by using the
minimum amount of administrative effort.
Usp_InsertInvoices.sql
Invoices.xml
All customer IDs are 11 digits. The first three digits of a customer ID represent the customer’s
country. The remaining eight digits are the customer’s account number.
The following is a sample of a customer invoice in XML format:
InvoicesByCustomer.sql
Legacy.sql
CountryFromID.sql
IndexManagement.sql
###EndCaseStudy###
Which data type should you use for CustomerID?
A.
varchar(11)
B.
bigint
C.
nvarchar(11)
D.
char(11)
Explanation:
Invoices.xml
All customer IDs are 11 digits. The first three digits of a customer ID represent the
customer’scountry. The remaining eight digits are the customer’s account number.
int: -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647) (just 10 digits max)
bigint: -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807)
http://msdn.microsoft.com/en-us/library/ms176089.aspx
http://msdn.microsoft.com/en-us/library/ms187745.aspx
Answer here is BIGINT, not CHAR(11).
BIGINT will fit the 11 digits and only use 8 bytes of storage. CHAR(11) will use 11 bytes. VARCHAR and NVARCHAR will use even more.
I think char(11) is correct.
In the example customer id ‘00156590099’, it states that the first 3 digits are the country code. If you were to store this number as a bigint, it would be displayed as ‘156590099’.
With char(11), the first three digits are 001, with bigint, they are 156, which would be a completely different country code.
How about nvarchar(11)? Usp_InsertInvoices.sql inserts customer ID as nvarchar(11):
CustomerID nvarchar(11) ‘Customer\@ID’
Or varchar(11)? Legacy.sql and CountryFromID.sql declare @CustomerID variable/parameter as varchar(11).
I believe question should be which data type you should not use. In that case we can easily rule out char, varchar and nvarchar.