Tuesday, March 27, 2012

advice normalization

I have a web app which is used to do normal insert/update of employee info. Connected to each employee that is entered is some data that is imported from an outside source for each employee. The question I have is currently my database is very normalized and importing data from this outside source will be quite a pain because of this. Is it bad practice to denormalize a specific table if no user will every insert/update it beside DTS?

Why do you feel that normalization will make data importation more difficult?
Normalization should make the process somewhat easier -- it helpsguarantee data integrity, so you won't have to put excessive amounts ofvalidation code into your importation routines. I would notrecommend denormalizing to make this process "easier". Dataintegrity is the most important factor, and is the reason we usedatabases instead of flat file systems!
Can you post some more information about your schema and the data you're trying to import?

|||No Denormalization is used in OLPT(online transaction processing) to improve performance. Run a search for Composite index in SQL Server BOL(books online). A Composite index can take 16 Columns with a size limit of 900 bytes. Hope this helps.|||No. OLTP databases should NEVER be denormalized when dataintegrity is important! Use of denormalization for performanceshould be limited to OLAP and reporting scenarios in which the data canbe re-built from a trusted source. I would never riskdenormalizing a transactional database for the sake ofperformance. Even the best performance will be utterly useless iftransactions are lost due to data integrity issues.
I'm unsure of what a composite index has to do with this topic, but thanks for throwing it out there.

|||OLTP(online transaction processing) is the general term for none analytical use of the database. Denormalization in SQL Server 2000 and below can be achieved through a Composite Index. A Composite index is a way of life in SQL Server 7.0 and below without built in DRI(declarative referential integrity) And the table in question is being used by a process not people so the access can be scheduled.|||I'm not sure how you've arrived at the conclusion that creating acomposite index is akin to denormalizing a table. Given thatindexes are physical, not logical parts of the schema, they are notconsidered in discussions of normalization. I'd recommend thatyou readthis, and other articles on the Database Debunkings website to dispell that notion.
But even if that were the case, it would not apply to thissituation. The OP is concerned that data importation is going tobe difficult due to the normalization of the database. But as Iassume you're aware, DML operations cannot be performed onindexes. Only on tables (and indirectly on tables via views andUDFs). Furthermore, large composite indexes will slow downimportation -- not speed it up. Therefore, creating large indexeswill serve to hinder -- not help -- the OP's importation efforts.

|||

AdamMachanic wrote:

I'm not sure how you've arrived at the conclusion that creating a composite index is akin to denormalizing a table. Given that indexes are physical, not logical parts of the schema, they are not considered in discussions of normalization.



Indexes are not considered because indexes are from vendors and Normalization is ANSI SQL but there are so many vendor implementations that makes the database better. In SQL Server 2005 it is taken to the next level with index column include. Try the link below for index covering used by Microsoft consulting and is considered good practice by the industry. While you are at it check the appendix of the book below to see why E.F.Code called it normalization. If it is not in the PPT online it became Normalization because Nixon have normalized relationship with China.

http://www.sql-server-performance.com/covering_indexes.asp

http://wings.buffalo.edu/mgmt/courses/mgtsand/data.html

|||It doesn't matter if something is a vendor extension or defined by theANSI Standard -- SQL and the ANSI Standard have absolutely nothing todo with normalization. As a matter of fact, I just searched thecomplete text of the SQL-99 standard and a form of the word 'normalize'appears only once -- in reference to normalization of datetimedatatypes!
What the Relational Model is concerned with is the distinction betweenthe logical and the physical. Tables are logical -- and thereforesubject to the rules of logical normalization. Indexes arephysical -- they have no bearing upon the logical schema.

|||I have ANSI 2003 and the person will take what meets their existing needs.|||

Caddre wrote:

I have ANSI 2003 and the person will take what meets their existing needs.


Where is normalization defined in the SQL 2003 standard?

|||We will not be having this conversion if you have used SQL Server 6.5 and below when SQL Server and Normalization are not in one sentence. What is Normalization when queries are taking hours to complete.|||What difficulties did you have with normalization in SQL Server 6.5?

No comments:

Post a Comment