[Overdog]

Originally Posted by alexander

...That's why i tinker with creating custom views, and i wouldn't even need that if the reporting engine they were using was anything decent, but the problem is, when you feed 500000+ records of 200 columns into a crystal (6, because of it's web interface licensing) report, and then have the report look for one of the records... SQL will return the data in literaly seconds, its efficient for what it does (methinks you would agree, its no MySQL for data retrieval, but MySQL is no MSSQL for record writing either... and i work a fair amount with MySQL databases, i am trying to change over to Postgres, and yeah, i guess somehow i get to deal with MS now.... hell, can anyone tell me how that's a part of my helpdesk job description?

Well, it's because there's such a big shortage of people who have database knowledge/skills. For example, the person who developed the crystal report you are talking about evidently had no idea that the right way to do this is to call a stored procedure in the database and pass parameters for the where clause so the database server returns exactly the records needed, and all crystal needs to is display them....

[alexander]

as i have mentioned, the reports are based on a view in the database, they are written according to the software manufacturer's specifications. Honestly the guy who wrote the 100 repors there has better ways to spend time then to read through 700+ pages of documentation of the database (there are probably 80-90 tables, and they are far from intuitive), to then reverseengineer the databases and be able to then bring down efficiency, plus that was not his function, he was not hired to do this, and probably won't be able to learn this stuff, not that he'd care to...

And there aint no way that i am letting anyone who's not a SQL pro to access the database directly, never mind storing procedures...
Case closed... Verdict: Flawed By Initial Design

[LaurieAG]

Hi Alexander,

Originally Posted by alexander

as i have mentioned, the reports are based on a view in the database, they are written according to the software manufacturer's specifications. Honestly the guy who wrote the 100 repors there has better ways to spend time then to read through 700+ pages of documentation of the database (there are probably 80-90 tables, and they are far from intuitive), to then reverseengineer the databases and be able to then bring down efficiency, plus that was not his function, he was not hired to do this, and probably won't be able to learn this stuff, not that he'd care to...

Surely he'd just take note of the structure of the key index fields from each table and just disregard elements in the view that are already represented at a higher level. Unless the idea was to have an obfuscated master view that was relatively meaningless to anybody unless they understood which duplicate field contained the real data

Originally Posted by alexander

And there aint no way that i am letting anyone who's not a SQL pro to access the database directly, never mind storing procedures...

Too right. I lost a good job in 1991 because a novice hooked up to my clients project management database (non SQL) externally and, instead of upgrading field definitions, populated all of the financial data fields with 'uuuuuuu', without making a backup! Why didn't they just issue a new software update that backed up the database and updated the fields automatically on its first run. At least the developer has a record of all historic data changes at hand.

BTW, In the late 80/early 90's DOS days I noticed that the only people in my office who had formatted their hard drives were electrical engineers.

[alexander]

Surely he'd just take note of the structure of the key index fields from each table and just disregard elements in the view that are already represented at a higher level.

It's not that difficult as some views allow you to see how they link the data in tables, but it's really less then simple, there are tables that are not linked, there are tables with useless fields that never get used, there are fully empty tables, and lastly there are tables that have random, and completely useless data in it. Problem is, there are various ways and tables that record the data, and when you start dealing with 15 different dates, all seemingly random, some put in by the DB engine, some by users, and so forth, it becomes simlply worthless to, without having solid SQL skillz (yes with the z, because skills wont help in this situation), try to reverse engineer this DB...

Wow thats a mighty big mistake, almost as bad as a friend of mine, who ran mk2fs instead of fsck on his drive and reinitialized the file system on his hard drive.... talking about loosing 2 months worth of projects and data