###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:
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
Should it not be B, then? bigint would fit the length limit, 64 bits can be represented by just 8 bytes rather than 11 and, furthermore, numbers are far quicker to index and seek than strings.
The first three digits of a customer ID represent the
customer’scountry. CAN YOU NOT SEE ?
Should be bigint
‘Digit’ can only be a number
appologise you are right
in the sample the customer country is 001
Digits which leading 0s are difficult to store/process within a bigint type.
Nonetheless, all CustomerID’s are still digits, part of which 8 digits comes from the customer’s Account Number. So, ‘bigint’ it is!!
if you use bigint you’ll have to convert it to varchar then pad it with zeroes if it’s less than 11 characters before creating an invoice. To join/compare/whatever with incoming invoices you’ll have to do the same, or convert the incoming data to bigint before doing anything with it.
Fixed length string is better than bigint in this case.
“Columns must be defined by using data types that minimize the amount of space used
by each table.”
tho this could make bigint correct answer