relational database questions

[Josh Davenport]

Ok Robert.

Please name a relational database.

Not 4D.
Seldom is anything more than 3rd degree normal in real world systems,  
and at that level or normality, orphaned junk pops up all over the  
place, or you have to add a bunch of holding tables... or... or.

Anyway, I just read the link you provided (not that I haven't studied  
relational theory, because I have, though its been a while). It gave  
basically the same caveats you do... about virtually everything,  
including SQL... which apparently isn't relational. And you know,  
they're right, its not, but then neither is filemaker.

Panorama is a relation database in the sense that most products  
marketed as RDMS designed for application at the workgroup level are  
relational. It sure as heck is as relational IN PRACTICE FOR CUSTOM  
SOLUTIONS as 4D, which is always an awful hack. You're perpetually  
creating arrays and jumping through hoops in that thing. Yeah, they  
allow you to draw little lines between fields. But try drawing a line  
from a Contact table to TWO different foreign (that's the word I was  
trying to remember) key fields in a table in 4D. You're screwed. Yet  
its a perfectly valid relational construct.  Or you skip the little  
lines and turn the relations on and off in code to get it to do what  
you want. Also, you always cheat to get the speed you need... hmmm.

Try building a Parts make Parts relation... ouch. And also perfectly  
valid.

Try turning on triggers and using transaction rollback, but not  
loosing an Invoice # after a failed invoice row insert, where the  
invoice# is (or was, at least) required by law to not contain a gap  
in the sequence.

The question is not whether Panorama has a JOIN statement. The  
question is whether, when you are programming a real world data  
structure, which humans have to use in an efficient manner, is it  
easier to butcher your nice neat relationships laid out in a more  
strict RDBMS, or create and maintain them in Panorama. I think often  
the answer is the later.

Would I like Panorama to support a few more things? Heck yeah.  
Cluster locking in particular. I think that's a serious limitation.  
But in my experience, for the audience for which I design, its more  
effort to work around the data integrity code in 4D than to create  
the data integrity code in Panorama.

Regards,

Josh


On Apr 30, 2008, at 6:57 PM, Robert Ameeti wrote:

> At 9:07 PM -0400, 4/29/08, Josh Davenport wrote:
>
>> 1) Panorama is a relational database,
>
> Not by any stretch of the imagination.
>
> See <http://en.wikipedia.org/wiki/Relational_database> and more  
> specifically <http://en.wikipedia.org/wiki/Relational_model> for  
> all of the reasons why Panorama is not a relational database.
>
> In short, a relational database would would follow the relational  
> model and would have "... aims that included avoiding, without loss  
> of completeness, the need to write computer programs to express  
> database queries and enforce database integrity constraints."
>
> As you well know, Panorama has no automatic, built in, method for  
> enforcing database integrity between tables. All of this is on the  
> shoulders of the programmer to create, integrate, & enforce.
> -- 
>
> <><><><><><><><><><><><><><><><><><>
> Robert Ameeti
>
> He played the king as if afraid someone else would play the ace.
>            -- John Mason Brown, drama critic
> <><><><><><><><><><><><><><><><><><>
> _______________________________________________
> Qna mailing list
> Qna at provue.com
> http://provue.com/mailman/listinfo/qna

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://provue.com/pipermail/qna/attachments/20080430/1d9c17f2/attachment.html