--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > How is this done in relational databases? There has some be some > sort > of language to evaluate the database. SQL is a language, I guess.
Yes, SQL is a language, but unlike M, but it's a very different sort of language. If you write FOR I=1:1:10 S A(I)=2*I+1 then you're giving a set of instructions for carrying out a task. On the other hand, the SQL query SELECT PATIENT_ID, ADMISSION_DATE FROM PATIENT WHERE (PATIENT_SEX="M" AND PATIENT_DOB > 1/1/1960) is a totally different type of animal, it's a *description* of a set of data, not a prescription for obtaining that data. It is up to the underlying DBMS to try and figure out how to respond to your query. If relational databases are sometimes slower than MUMPS systems, it's because they are designed to respond to non-procedural queries. In theory, a good query optimizer could go a long way toward making the translation from SQL to procedural code, but that does not change the underlying point: SQL (or, more abstractly, relational algebra) is not a procedural language. > > It seems that a M database is a more "organic" creature -- containing > code to protect itself etc. Or, at least, that code is more visible to the application programmer. > Probably relational databases can do > this > too, but at our site at least, it is not done. For example, when our > front staff put in goofy social security numbers, the database is > perfectly happy to accept these erroneous values. In fact, most relational databases will allow you to specify constraints involving specific patterns (MATCHES). In addition, other types of integrity constraints are often specified (e.g., a foreign key may be qualified with something like REFERENCES PATIENT.ID, making it impossible to enter a key not found in the other table), but it's not uncommon to disable enforcement of these constraint (or, rather, relegate it to front-end applications). In fact, I don't even think MySQL 4.0 implemewnts these kinds of contraints. You can include them in your table definitions, and they will be politely accepted (and ignored). I don't about later versions. > > So I am guessing that to be insulated from M would require an > introduction of some different language as a replacement. I don't follow you. The implementation language need not have anything to do with the language application programmers use to interact with the database. The DBS calls go a long way toward achieving language independence of the type I'm describing, but there are still things that require you to reference the underlying globals. Sure, you work with the DBS APIs in MUMPS, but the fact that your code is written in MUMPS is really incidental. Once you start $ORDERing through a cross-reference, then your choice of language is no longer incidental, and your application becomes more tightly bound to the underlying representation. >I can't > see > that happening. > Maybe not, but one thing is sure: It never will happen if everyone just shrugs their shoulders and says that they can't see it happening. Defeatism is not the way to make VistA succeed. === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
