It's important to strive for quality, consistency, and effectiveness in all documentation projects. To achieve these goals, we have created the following review checklist to ensure accuracy …Full description
Full description
dbmsFull description
The main objective of Shoe Store Billing Management System is to Computerized the billing part of the Bata Store. This project developed using Visual basic 6.0 and Microsoft Access Driver.
helpfull information to control completeness works in PCB design
asic flowFull description
AIA Design Development Checklist
Warning, your test questions may be in other order or completely different.Full description
Hospital Management System Database Design Data types and its description:
Checklist for architectural design studentsFull description
Full description
Cód. ps3 gamesFull description
'kyjk
Fire Pump Installation Plan Review ChecklistFull description
MCQ on DatabaseFull description
Descripción completa
90% 3D Model Review
SIM databaseDeskripsi lengkap
DATABASE DESIGN/REVI Project Name : Target DB/Schema Name : DB Script File Name : Reviewed By (Review Date) : Verified By (Verification Date) :
Check List General Do not use spaces in the name of database objects Do not use SQL keywords as the name of database objects Use upper case for all SQL keywords (SELECT, INSERT, UPDATE, UPDATE, WHERE, AND, etc) Comment codes that are not easily understandable -> Use single-line markers(--) -> Reserve mult-line(/*.. ..*/) comments for blocking out section of code Use BEGIN..END BEGIN..END blocks only when multiple statements are present within a conditional code segment. Place SET statements before any executing code in the procedure. Return multiple result sets from one stored procedure to avoid trips from the application server to SQL server Do not use cursors or application loops to do inserts. Instead, use INSERT INTO Fully qualify tables and column names in JOINs Do not forget to enforce unique constraints on your alternate keys. Do not define default values for parameters. parameters. If a default is needed, the front end will supply the value. Do not use column numbers in the ORDER BY clause. Do not use GOTO. Check the global variable @@ERROR immediately after executing a data manipulation statement (like INSERT/UPDATE/DELETE), INSERT/UPDATE/DELETE), so that you can rollback the transaction if an error occurs Or use TRY/CATCH Do basic validations in the front-end itself during data entry Off-load tasks, like like string manipulations, concatenations, concatenations, row conversions etc., to the front-end applications if these operations are numbering, case conversions, type going to consume more CPU cycles on the database server Always use a column list in your INSERT statements. This helps avoid problems when the table structure changes (like adding or dropping a column). Minimize the use of NULLs, as they often confuse front-end applications, unless the applications are coded intelligently to eliminate NULLs or convert the NULLs into some other form. When executing an UPDATE or DELETE statement, use the primary key in the WHERE condition, if possible. This reduces error possibilities. Always store 4 digit years instead of 2 digit years in dates (especially when using CHAR or INT datatype columns) to avoid any confusion and problems.
Compliance Yes/No
Avoid dynamic SQL statements as much as possible. Do not call functions repeatedly within your stored procedures, triggers, functions and batches. Default constraints must be defined at the column level. Define all constraints, other than defaults, at the table level. When a result set is not needed, use syntax that does not return a result set. Constraints that apply to more than one column must be defined at the table level. Table Prefix table names with the owner name Table names should end with an 's' (Eg. Products, Customers) Each table must have a primary key Columns Each column name must be unique within its table. Do not use reserved or key words as object names. The name can have a maximum of 18 characters. If a column references another table’s table’s column, name it ID (Example: The Customers table has an ID column The Orders table should have a CustomerID column) In VARCHAR data columns, do not default to NULL; use an empty string instead Columns with default values should not allow NULLs Avoid using TEXT or NTEXT datatypes for storing large textual data. Use the CHAR data type for a column only when the column is nonnullable. Use Unicode datatypes, like NCHAR, NVARCHAR, NVARCHAR, or NTEXT, if your database is going to store not just plain English characters but a variety of characters used all over the world. Use these datatypes only when they are absolutely needed as they use twice as much space as non-Unicode datatypes. Indexes Primary keys have a prefix of 'PK'. Foreign keys have a prefix of 'FKx' where x is a number that is incrementally assigned. Clustered indexes have a prefix of 'IDX'. The application of the appropriate prefix should follow the following hierarchy: primary key, clustered index, foreign key, other index. E.g., an index that is both a primary key and clustered should have a prefix of 'PK'. Indexes: IX___ (Eg. IX_Products_ProductID) Primary Keys: PK_ (Eg. PK_Products) Foreign Keys: FK__ (Eg. FK_Products_Orderss) Stored Procedures & Triggers
Stored Procedure : sp_[_]
(Eg. spOrders_GetNewOrders, spOrders_GetNewOrders, spProducts_UpdatePr spProducts_UpdateProduct) oduct) Do not prefix stored procedures with ‘sp_’ As much as possible, create stored procedures on the same databse as the main tables they will be accessing Use SET NOCOUNT ON at the beginning of stored procedures Fully qualify all stored procedure and table references in stored procedures. Do not use the RECOMPILE option for stored procedures. Place all DECLARE statements before any other code in the procedure. Always add an @Debug parameter to your stored procedures. Do not call functions repeatedly within your stored procedures, triggers, functions and batches. Make sure your stored procedures always return a value indicating their status. If your stored procedure always returns a single row resultset, consider returning the resultset using OUTPUT parameters instead of a SELECT statement, Triggers: TR__ (Eg. TR_Orders_UpdateProducts) Variable identifiers for datatypes should consist of two parts: ->The base, which describes the content of the variable; ->The prefix, which describes describes the datatype of the variable variable (Eg. @chrFirstName) Performance Considerations Make sure your queries do an "Index seek" instead of an "Index scan" or a "Table scan." Initially, your data should be normalized at least to the third normal form. If you then need to denormalize some of the data to improve performance, you may do so. There should be a documented rationale for all denormalization activities. Do not use 'SELECT *' in your queries. Avoid the creation of temporary tables while processing data as much as possible Try to avoid wildcard characters at the beginning of a word while searching using the LIKE keyword as that results in a full table scan, Avoid searching using not equals operators (<> and NOT) as they result in table and index scans. Use derived tables wherever possible, as they perform better. Use SET NOCOUNT ON at the beginning of your SQL batches, stored procedures and triggers in production environments, Perform all your referential integrity checks and data validations using constraints (foreign key and check constraints) instead of triggers, as they are faster. Use triggers only for auditing, custom tasks and validations that cannot be performed using constraints. If you have a choice, do not store binary or image files (Binary Large Objects or BLOBs) inside the database. Instead, store the path to the binary or image file in the database and use that as a pointer to the actual binary file stored elsewhere on a server. Avoid dynamic SQL statements as much as possible.
Try to avoid server side cursors as much as possible.If a cursor is unavoidable, use a WHILE loop instead. A WHILE loop is always faster than a cursor. Avoid Deadlock Always access tables in the same order in all your stored procedures and triggers consistently. Keep your transactions as short as possible. Touch the least amount of data possible during a transaction. Do not wait for user input in the middle of a transaction. Do not use higher level locking hints or restrictive isolation levels unless they are absolutely needed. Make your front-end applications deadlock-intelligent, that is, these applications should be able to resubmit the transaction in case the previous transaction fails with error 1205. In your applications, process all the results returned by SQL Server immediately so that the locks on the processed rows are released, hence no blocking. Security To be able to access data from a database, a user must pass through two stages of authentication, one at the SQL Server level and the other at the database level. These two stages are implemented using Login names and User accounts respectively.
