Why does everyone beat on us old Cobol guys? What does Cobol have to do with designing a relational database?
You can't export or imort databases easily with dts, when relations are defiened in the database. This gave me one hell of a bad time! The Database is the wrong place for documentation.
Yeah, a bit mean on the COBOL guys...also worth remembering that they're probably all loaded after the whole Y2K debacle - never hurts to have rich friends! Anyway, my next biggest DB issue (after yours which is THE biggy) is incorrect / poor use of indexes...grr...it doesn't matter how smart your query is or how good your relations are, if your indexes are crap / non-existent, the performance will suck!
Hi Roy,
Ocasionally I am using not normalized DataBases .
And such cases are exactly when you have super cumbersome logic and huge amout of records.
From the second side you requested aftest perforamnce for reports, ubpdates etc. and hundreds hits in minute for your web application.
And more, I spoke about DB thet was normalized in the early life's stages.
//After code review :-))
Hi Roy,
Ocasionally I am using not normalized DataBases .
And such cases are exactly when you have super cumbersome logic and huge amout of records.
From the second side you requested for fastest perforamnce for reports, updates etc. and hundreds hits in minute for your web application.
And more, I spoke about DB that was normalized in the early life's stages.
Of course sometimes you HAVE to remove relations. I'm not talking about the exceptions to the rule here. I'm talking about people not implementing the rule when the can and SHOULD implement it.
This is a little confusing. If the database has a single table and the table has a single column, then it has a relation. It sounds like you are really talking about relational integrity, i.e., the relationships between relations (tables).
Roy *is* speaking about relational integrity, and a database without it isn't really a relational database. In order for a "single column table" to be a table (in a relational sense) the single-column has to be defined as a primary key, with a unique constraint. The fact that SQL Server allows you to do otherwise is the root of the problem. It's all too easy in SQL to create a "table" with no primary key, or omit a foreign key constraint, and before you know it you are writing funky business logic to enforce rules that should be in the database. Or, more likely, finding weird bugs because you forgot to write the funky business logic.