June 15, 2006 at 6:18 pm
Without knowing it does infact do it, I don't really have time to look into it.
To be honest, the downsides to Crystal according to testimonials don't really lead me to want to just play around with it.
Myth or not, I see other devs writing:
1) Poor deployability
2) Unreliable operation (constant server restarting needed)
3) Difficult to get to the point of proof of concept.
4) High licensing cost, while considering points 1-3
This is in comparison to tools developed by other companies for reporting.
Thanks anyway.
June 15, 2006 at 6:23 pm
I really wasn't trying to recommend a product. Instead, I was asking whether it made sense to use native SQL to do what I see as a pure reporting function an any reporting framework worth the money should handle.
I've found myself several times reinventing the same wheel someone else has already been using for a while.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
June 15, 2006 at 6:30 pm
So far I have not had a recent need for it, but this need was back in 2001.
One reason why a lot of developers reinvent the wheel is because:
1) They are not aware the wheel they need exists
2) Other people's wheels are not 100% guaranteed to be bug free.
(just a few months ago, ran into a java bug on CFMX, does absolute date compares, so datediff of days spanning a daylight savings results in 1 less days)
June 15, 2006 at 7:40 pm
I get your point, and feel your pain, regarding the subject of over-normalization. However, that being said, you picked a bad example of the genre. I can think of several reasons for this design: the need to link a calendar day to a 5-5-4 retail week being the most obvious, your queries work better if the tables are indexed with anything but a date (especially in sqlserver where it always has a time attached) etc. etc. When you populate your date table you always do it from some kind of standard proc and you do it for a 10 or twenty year interval, or you do it once a year if you want to handle floating retail holiday periods.
Anyway, if you want to talk about over-normalization, let's talk about a well-known time-and-attendance system which I had the misfortune to set up for etl to a data-warehouse. This baby had no less than two internal hierarchies, connected by enough many-to-many relationships to choke a camel. The ERD for this thing covered my cubicle wall. The total intellectual poverty of this so-called system was illustrated by the fact that the only true source of the position of any object in any hierarchy was a field containing the textual representation of the hierarchy (names separated by slashes).
My point is this: left to their own devices, programmers these days will create a table and dump stuff into it as they see fit. Because they are so involved in the total whiz-bang groovieness of whatever interface they are working with, they are blind to the real structure of any application:the database objects behind it.
Nobody shoud get within shouting distance of a database until they have written a couple of CICS applications with an IMS backbone.
June 15, 2006 at 7:55 pm
Hard to argue with either of those points, the first mostly. Yeah, usually I was unaware the wheel existed until I got fed up trying to make my own wheel "round enough" and went looking.
The second point is a good one but how do you know your own solution is 100% bug free? At least if you buy a solution you should get support with it.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
June 16, 2006 at 8:33 am
If the primary key on the Date table is int identity(1,1) then the design is bad.
If Data table uses int for the form 19000101 thru 20061231 then it's not so bad
What is wrong with using a FK to insure the date is valid?
Viewing 6 posts - 31 through 35 (of 35 total)
You must be logged in to reply to this topic. Login to reply