Cartensian joins were an impossibility. I got my join modifiers mixed up. Everything was like a "standard?" join, essentially the 2nd & 3rd parameters of the function became the (where this_table.field_name = lookup_table.field_name ) construct of an SQL where. I meant the overhead was essentially the same as a relational DB doing a non-Cartesian join. So for a field named inv_amount defined as trans(invoices,inv_id,amount,'x') in customer table, in SQL-speak becomes select c.cust_name, c.inv_id, i.amount from customer c, invoices i where c.inv_id+ = i.invoice_id;
In Pick-speak: select cust_name, inv_id, inv_amount from customer Add sorting, grouping, totaling, limits, etc. as necessary. Notice, if the customer didn't have any invoices it still created a line of output, thus the left-join syntax in the SQL version. Also, the database was designed with nested tables in mind, so the inv_id field could contain multiple values, essentially a list of all that customer's invoice ids. Also, it only contained single-column primary keys, and the trans function always did compares against the PK. If you needed multi-column PKs, you could do it, but had to code for it yourself. Of course, nobody really uses multi-column PKs right? (Note, even for Pick, the above is a bad example, since an invoice ID list could get huge, thus slowing access to the regular data. Data was stored as delimited strings of varying lengths. You could, however, work around it physically, but still have it appear logically this way.) > -----Original Message----- > From: Martin Gainty [mailto:mgai...@hotmail.com] > Sent: Thursday, September 30, 2010 12:30 PM > To: Tomcat Users List > Subject: RE: [OT] RE: Tomcat Consultant > > > i agree ..caching works well for previously referenced entities > natural joins work if the column names are identical that is > table1.engineering==table2.engineering > but engineering==eng would not work for natural join and consequently > fallback to cartesian join > which would of course slow the query to a crawl > > an interesting digression > Martin > ______________________________________________ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de > confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede > unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. > Diese Nachricht dient lediglich dem Austausch von Informationen und > entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten > Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt > uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas > le destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la > copie de ceci est interdite. Ce message sert à l'information seulement > et n'aura pas n'importe quel effet légalement obligatoire. Étant donné > que les email peuvent facilement être sujets à la manipulation, nous ne > pouvons accepter aucune responsabilité pour le contenu fourni. > > > > > > > Subject: RE: [OT] RE: Tomcat Consultant > > Date: Thu, 30 Sep 2010 12:12:41 -0500 > > From: jeffrey.jan...@polydyne.com > > To: users@tomcat.apache.org > > > > > -----Original Message----- > > > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > > > Sent: Thursday, September 30, 2010 10:41 AM > > > To: Tomcat Users List > > > Subject: Re: [OT] RE: Tomcat Consultant > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Martin, > > > > > > On 9/30/2010 10:50 AM, Martin Gainty wrote: > > > > i would be interested in what administration overhead with this > > > > translate_entry table > > > > > > Probably about the same as doing a CREATE VIEW. > > > > > Actually more like a JOIN. The run-time loaded in and cached the > necessary rows from the lookup tables and pulled the data fields > needed. Essentially though, it was more like a left-join. To get the > effect of a natural join, you had to add a where clause to exclude > lines with null lookup return-values. I'm not sure if you could do a > full-join, but I never had need to. > > > > > _______________________________________________________________________ > ___ > > > > Confidentiality Notice: This Transmission (including any attachments) > may contain information that is privileged, confidential, and exempt > from disclosure under applicable law. If the reader of this message is > not the intended recipient you are hereby notified that any > dissemination, distribution, or copying of this communication is > strictly prohibited. > > > > If you have received this transmission in error, please immediately > reply to the sender or telephone (512) 343-9100 and delete this > transmission from your system. > __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
