For the end user, it was just another field in the data dictionary for the table. The actual entry would be a line of code which was really a function call: TRANS(lookup_table_name,lookup_id,return_field,not_found_code) That last entry was a code that told the run-time engine what to return if the lookup_id was not found. The run-time engine had some tricks to make this efficient. The data dictionary basically defined two type of entries: D for data, which had a field# (column) to return, and I for Interpreted, so you could add calculations directly to the dictionary. The translate/lookup was one, but you could put anything expression there, even call complicated self-written functions, or if statements, etc. It used the same language that you wrote programs in. A standard example would be an extended cost. The entry would just be QTY * COST. The idea was that the DBA defined everything you might want to use. If you needed a new calculation, it could be added to the dictionary rather quickly and available immediately. At later releases, primarily to support SQL queries, they added the ability to add Trans functions and code in-line with the query, so you could by-pass the DBA if necessary, but it was suggested to do this primarily as a dev/debug step. It was faster if it was compiled into the dictionary. You further defined in the dictionary things such as precision, display length, etc. Therefore, you could have more that one dictionary entries pointing to the same field or calculation, but returning slightly different results.
Now true PICK, defined the dictionary types as A for attribute (field/column), and S for Stack. The S-type was the calculated field, and all work was done using a calculation stack. It was also how you did table lookups. These could get really complicated. I put a number up there with the one-line obfuscated C programs some folks are so proud of. > -----Original Message----- > From: Martin Gainty [mailto:mgai...@hotmail.com] > Sent: Thursday, September 30, 2010 9:51 AM > To: Tomcat Users List > Subject: RE: [OT] RE: Tomcat Consultant > > > i would be interested in what administration overhead with this > translate_entry table > > if your goal is a lexicographical approach you could pull the data > dictionary build routines from a search engine such as lucene > or solr..that way you could handle modifiers such as adjectives and or > adverbs > > with exception of BBN's dictionary i havent seen any products which > address the need > > an interesting digression! > Martin Gainty > ______________________________________________ > 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 09:32:47 -0500 > > From: jeffrey.jan...@polydyne.com > > To: users@tomcat.apache.org > > > > > -----Original Message----- > > > From: Martin Gainty [mailto:mgai...@hotmail.com] > > > Sent: Thursday, September 30, 2010 9:18 AM > > > To: Tomcat Users List > > > Subject: RE: [OT] RE: Tomcat Consultant > > > > > > > > > this is way O/T so lets take this offline > > > what is meant by "near-english query"? > > > > > > M > > > > I believe the technical term most folks use is "natural language > query". > > > > The tables where dictionary-based, and you didn't really have joins. > If > > there was a need to reference data from another table, using foreign > > keys, you added a translate entry to the database for the necessary > > fields. > > Then instead of needing to use and understand SQL, you simple said > > something like: > > Select customer_name, address, invoice_id, total invoice_amt from > > customer-table by customer_name; > > and you got a nice table listing each customer and its invoices with > a > > total invoice amount per customer and a grand total at the end. > > > > > _______________________________________________________________________ > ___ > > > > 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 > > > __________________________________________________________________________ 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
