well, (smile) I didn't say *I* saw violation of FNF as an objection. I think my statement is true - many would see it as a violation of FNF. Many others like you might argue differently.
I first got into this business nearly 20 years ago when I came to realise the severe limitations of the relational algebra. Nothing much has changed about that - it can still be very cumbersome, to say the least. So I'm not dogmatic about obeying some design law that some theorist has laid down. It's more like the English grammar rule about split infinitives - I understand why some people disagree with the rule (or deny it exists), but I still (almost) never use split infinitives myself - I just don't find the need.
*shrug* Never mind - I'll go back to wrestling with Ant now.
cheers
andrew
Merlin Moncure wrote:
Andrew wrote:
It's in the SQL99 standard. There's nothing forcing you to use them -I
am a (possibly) old-fashioned data architect, so I never use them ;-)
SQL99 actually allows you to use more or less arbitrary compositetypes
as columns (although Pg currently doesn't) - many would argue thatthis
violates first normal form.<snip>
I would (strongly) disagree with your last statement: I believe the
opposite to be true. I do agree that they are a violation of the first
normal form when used a mechanism for general data storage; however the
intent here is for arrays to help get around sql's difficulty (largely
due to the lack of recursive queries in postgres, but also in a more
general way) in dealing with post-query related data.
Arrays (as a result of a query) help to enhance relational use of the database by indirectly allowing a more natural method of storage by giving you more power to query the data. The main problem is sql's general treatment of results sets as two dimensional tables when in fact they are just possible branch points in a 'n' dimensional space (specially expressed by arrays in limited, but useful circumstances).
In other words, arrays for input = bad, arrays for output = not so bad. When recursive queries become available, I'll probably use them instead(I've never had the luxury), but in the mean time...
p.s. Joe, you were right I did misunderstand both you and postgres's
capabilities at the present time. The functionality in your example was
exactly what I was looking for. I still hold to my point that if the
array is performing deep copies upon growth, there can be vast speed
improvements in cases (such as during the array aggregation) when
aggressive growth can be predicted in advance. The worst case of
'reallocate after each aggregation' can be particularly bad. In any
case, I'll shut up now :)
Regards, Merlin
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
