###BeginCaseStudy###
Case Study: 4
Scenario 4
Application Information
You are a database administrator for a manufacturing company.
You have an application that stores product data. The data will be converted to technical
diagrams for the manufacturing process.
The product details are stored in XML format. Each XML must contain only one product that
has a root element named Product. A schema named Production.ProductSchema has been
created for the products xml.
You develop a Microsoft .NET Framework assembly named ProcessProducts.dll that will be
used to convert the XML files to diagrams. The diagrams will be stored in the database as
images. ProcessProducts.dll contains one class named ProcessProduct that has a method
name of Convert(). ProcessProducts.dll was created by using a source code file named
ProcessProduct.es.
All of the files are located in C:\Products\.
The application has several performance and security issues.
You will create a new database named ProductsDB on a new server that has SQL Server
2012 installed. ProductsDB will support the application.
The following graphic shows the planned tables for ProductsDB:
You will also add a sequence named Production.ProductID_Seq.
You plan to create two certificates named DBCert and ProductsCert. You will create
ProductsCert in master. You will create DBCert in ProductsDB.
You have an application that executes dynamic T-SQL statements against ProductsDB. A
sample of the queries generated by the application appears in Dynamic.sql.
Application Requirements
The planned database has the following requirements:
• All stored procedures must be signed.
• The amount of disk space must be minimized.
• Administrative effort must be minimized at all times.
• The original product details must be stored in the database.
• An XML schema must be used to validate the product details.
• The assembly must be accessible by using T-SQL commands.
• A table-valued function will be created to search products by type.
• Backups must be protected by using the highest level of encryption.
• Dynamic T-SQL statements must be converted to stored procedures.
• Indexes must be optimized periodically based on their fragmentation.
• Manufacturing steps stored in the ManufacturingSteps table must refer to a product by
the sameidentifier used by the Products table.
ProductDetails_Insert.sql
Product, xml
All product types are 11 digits. The first five digits of the product id reference the category of
the product and the remaining six digits are the subcategory of the product.
The following is a sample customer invoice in XML format:
ProductsByProductType.sql
Dynamic.sql
Category FromType.sql
IndexManagement.sql
###EndCaseStudy###
Which data type should you use for ProductType?
A.
varchar(11)
B.
nvarchar(11)
C.
char(11)
D.
bigint
It can’t be option C. ProductType is numeric in nature (int or bigint). Not ‘int’ because it would contain 11 digits; so, should be ‘bigint’
All product types are 11 digits. The first five digits of the product id reference the category of the product and the remaining six digits are the subcategory of the product.
C is the right answer. Just look at the procedure CategoryFromType to confirm that you can’t use a numeric type because of the leading zeros that are part of the category code.
I won’t necessarily adopt the CategoryID format in CategoryFromType where leading zeroes are used. The scenario rightly states that “All product types are 11 digits. The first five digits of the product id reference the category of the product and the remaining six digits are the subcategory of the product.”
It has to be an integer data type: int or bigint. Change the leading zeroes to something that works with indexing.
OK, agreed. Read up on it, and I have to agree the answer is C.
Agreed with Lia, whoever says bigint is never been in any serious database development work.
It is a foundamental difference between string data type and integer datatype.
Firstly in the context of the case study, there is stored procedure “CategoryFromType” clearly trying to parse producttype field with a string function, this sp will be broken if producttype field has its data type changed.
Not in the context of the case study, we can’t change a field to numeric just because it looks like so. Just an exmaple, it is very dangerous to assume the leading zero of the producttype field never runs out, if it does runs out, the company may decide to use alpha letter. So below is all valid value for producttype field:
00000XXXXXXXXXXX
10000XXXXXXXXXXX
20000XXXXXXXXXXX
30000XXXXXXXXXXX
40000XXXXXXXXXXX
50000XXXXXXXXXXX
60000XXXXXXXXXXX
70000XXXXXXXXXXX
80000XXXXXXXXXXX
90000XXXXXXXXXXX
A0000XXXXXXXXXXX
B0000XXXXXXXXXXX
With producttype field changed to numeric, this won’t be allowed. And change the producttype data type to numeric to character type is catastrophic to development effort.