[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-normalised field Provides in UDD table



Andreas Tille <andreas@an3as.eu> writes:
>> Huh! That is ugly! Who made this???
>
> Probably the person who had the intention to add control file
> information verbosely to a database table.  I had discussed things like
> this years ago (debian-qa@lists.debian.org with [UDD] in subject is the
> right place to discuss this).  You could even argue that someonw is
> interested in the sequence of the dependencies (not that I personally
> would like this argument).  I was told UDD was *never* intended to be a
> normalised database and you always find arguments pro and contra
> normalisation.

>From your experience: do you think there are chances to get an
additional table with normalized dependencies?

Queries like for reverse dependencies or reverse suggestions seem quite
normal to me. Especially when it is called "Ultimate" :-)

>> But solving this on client side sounds like an ugly hack to me.
>
> Yes.  Didn't I told you that server side queries tend to be complex?
>
> The good thing about PostgreSQL is that it has really nice features.
> I'm using arrays to solve this.  To get the authoritative answer you
> were seeking above just do:

I would probably prefer to use a (temporary) view here, since it could
then work as if the database was normalized. But I have to learn more
Postgresql first... And the performance problem persists ofcourse.

> PS:  The main reason to use UDD was the "Architecture: any" feature.  As
> far as I can see that's not implemented yet and left for a future
> release.  That's perfectly fine since the current implementation is even
> now better than the old Perl script.  I just want to make sure that I
> have tested all new features.

We had a short discussion in

https://lists.debian.org/debian-blends/2018/03/msg00059.html

and your answer. Do you mean something more?

Best regards

Ole

P.S. please excuse the harsh tone of my last mail, that was not really
intended.


Reply to: