|
|
Posted by Bart op de grote markt on 11/26/07 15:52
On 26 nov, 14:09, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@greenms.com> wrote:
> "Bart op de grote markt" <warn...@googlemail.com> wrote in messagenews:3e7b897e-7ff7-436f-9291-adc2ab732c32@s36g2000prg.googlegroups.com...
>
> > On 25 nov, 19:59, --CELKO-- <jcelko...@earthlink.net> wrote:
> >> >> I guess there is no function to do this... What is the simplest
> >> >> solution? <<
>
> >> Do it in the front end instead violating 1NF in the Database side.
>
> > Hi,
>
> > I'm not an expert in that area, but I thought NF had to do with
> > database design and not with querying a database? Correct me if I'm
> > wrong.
>
> You're "wrong".
>
> You can't really separate the two. That's like saying that wheels on a car
> have to do with the design, not with the actual driving.
>
> If you design your database properly, your queries follow from that.
I have not said that database design has nothing to do with querying a
database... But a query of a database is combining the available data
to hava a certain result. Putting the normal forms into your database
is a way to avoid data loss in your database when you update or delete
your data. If I query a database for a report, then the result won't
interfere with the database itself, it just gives a view on your data.
I don't want to be offensive or so, but I'm not convinced yet.
And ok, I did not design the database... it is a database from a new
application my company bought. (In fact it's about two databases from
two different applications that have to be linked in a report, but I
won't go too far to explain that :-) )
> > I would like most of the logic on server side, (the report result is
> > retrieved by an excel report that mainly adds lay-out and adds the
> > possibility to further process the results) because when an update of
> > the report is needed, I only need to change the stored procedure and
> > not the 'front-end' excel reports with everybody that uses it.
>
> Then do it in a middle layer. What happens when your DB changes for other
> reasons but your reports aren't supposed to?
>
As has been said by J above, the Stored Procedure acts as middle layer
between the database and the reports. If there is an update of the
database (e.g. new product version), I will adapt the stored
procedure, so that the user doesn't even notice that anything has
changed.
Kind regards and thx for all your comments
Bart
Navigation:
[Reply to this message]
|