SQL
in [OOP]
|
From: Oliver Wong on 2 Feb 2006 15:08 "Alfredo Novoa" <alfredo_novoa(a)hotmail.com> wrote in message news:1138628504.735894.120650(a)z14g2000cwz.googlegroups.com... > Hi, > >>If true, then we are in for some nasty SQL viruses. > > No, because TC has nothing to do with viruses. To develop viruses we > need to have access to low the level operating system API. If we define "Virus" as a (sub-)program which attaches itself to other programs, then yes, any computing device that is a Universal Turing Machine is capable of hosting viruses. Programs are stored on the tape, and programs are capable of modifying the tape. Determistic Finite Automatas can't modify the location where programs are stored (i.e. the states themselves), and so there are no DFA viruses, for example. - Oliver
From: Patrick May on 2 Feb 2006 15:58 "topmind" <topmind(a)technologist.com> writes: > > > To keep the discussion on track, I will generally stick to biz > > > apps here. > > > > What exactly do you mean by "biz apps?" Are you using that > > term as a synonym for "CRUD data pipelines?" [ . . . ] > Call them whatever you want. Unless you can show a public example > and why it is more "complex" then something else, that is not really > usable info. Anecdotes and personal internal opinions are a dime a > dozen. You failed to answer the question. What exactly do you mean by the term "biz app?" Do you consider systems like OSSs, MRP/ERP/Financials integration, and clearing and settlement systems to be business applications or do you limit that term to describe CRUD processing? > > > Most non-trivial biz apps will be helped by a RDB. I have seen > > > very few exceptions given. > > > > That's not the point under discussion. You asked why tables > > don't model problem domains as well as OO constructs. That > > question has been answered. > > Not. No specific scenarios given. If you feel the arguments presented by myself and, more eloquently, Mr. Lahman unconvincing, please identify your specific concerns. Your rhetorical ploy of asking for scenarios that you will then use to take the discussion down multiple ratholes is easily recognized given your history and is no less disingenuous now than it has ever been. The answers given to you have been given are independent of particular scenarios. Here is the history for your convenience: > > > You asked "But how are tables less close to the domain than > > > classes, methods, and attributes?" The answer is, they lack > > > behavior. The most common language for manipulating tables is > > > SQL and it is not as powerful as general purpose OO languages. > > > > How does not covering the entire behavior spectrum make it "less > > close" to the domain? > > As Mr. Lahman has eloquently pointed out, only CRUD/USER > applications map directly to the relational model. Other > applications require different models of both data and behavior. > Since SQL has a limited support for modeling behavior relative to > general purpose languages, by your own admission, it is less capable > of reflecting the abstractions of problem domains other than those > of CRUD data pipelines. What objections do you have to that position? > [Deleted mutator issues. Mutators immaterial to this discussion] Another claim you are unable to support. How unsurprising. > > So yet again you have made a bunch of unfounded assertions > > with no capability or intention of backing them up. Have you even > > a passing acquaintance with the concept of intellectual honesty? > > No, you are just trying to make an international tribune out of side > opinions. If you wish to know if a claim of mine is something > formal, then please ask. So the base assumption should be that you are spewing unsubstantiated nonsense unless you clearly state otherwise? That was my working assumption, but I'm surprised to see you admit it. Flaming aside, making claims that you cannot or will not support in the course of a public discussion is grossly dishonest. You use these assertions to argue against well-supported positions of other participants in this newsgroup. Do you really want to publicly state that all of your statements should be consider lies unless labeled otherwise? > > You are, I suspect deliberately, avoiding the point. You > > asserted that all NFRs in an enterprise system could be met by > > 'purchasing a "big-iron" RDBMS. > > I did NOT say ALL! My statement has been misrepresented here. Your exact words were: I would note that a lot of the issues you mentioned, such as performance, scalability, resiliency, and recoverability can be obtained by purchasing a "big-iron" RDBMS such as Oracle or DB2. In context, this is clearly a claim that performance, scalability, resiliency, and recoverability can be provided to enterprise systems solely through the use of Oracle or DB2. Anyone willing to look through the thread will see that you were attempting to convey the idea that big RDBMSs are all that is necessary to meet the needs of enterprise systems. That's nonsense. > > Again, you appear to be deliberately missing the point. It > > isn't a matter of ACLs failing, it's a matter of them not even > > being capable of addressing the security requirements that are met > > by systems like Kerberos. > > What is the difference? Just pick something that Kerbo does well and > show why RDB/ACL's fail it. Why are you resisting? Since you clearly aren't interested in learning anything about the topic you're embarrassing yourself about, even when pointers to the documentation are provided, here is a quick summary for you. Kerberos is a service that allows mutual authentication between users and services in a distributed system. By design, it avoids the need to re-enter passwords for each interaction. What is important to this discussion is the protocol. Simply having ACL information accessible via a database provides no value against the threat models addressed by Kerberos. Realize that this is just one set of security requirements typically found in enterprise systems and you will see why your statement that "security is mostly just massive ACL tables" is laughable. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: Patrick May on 2 Feb 2006 16:05 "topmind" <topmind(a)technologist.com> writes: > > > Even assembler has a lot of implementations. They claimed > > > "significantly less code". I gave them a sample application and > > > they made up every (lame) excuse under the sun. But that is > > > another matter. FP is not the topic. > > > > I ask this question for the same reason and much the same > > feeling as when I take a good look at a serious accident > > encountered on the highway, but could you please point me to the > > location of this discussion? > > Sure. You will fit right in with the "We don't need no stinkin' > public evidence" crowd there. What is yet one more anecdite. Given your history of repeatedly refusing to support your assertions, your snide comments are not only unjustified but outrageously hypocritical. > http://c2.com/cgi/wiki?ChallengeSixVersusFpDiscussion Thank you for the link. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: topmind on 2 Feb 2006 19:47 > > > What exactly do you mean by "biz apps?" Are you using that > > > term as a synonym for "CRUD data pipelines?" > [ . . . ] > > Call them whatever you want. Unless you can show a public example > > and why it is more "complex" then something else, that is not really > > usable info. Anecdotes and personal internal opinions are a dime a > > dozen. > > You failed to answer the question. What exactly do you mean by > the term "biz app?" Do you consider systems like OSSs, > MRP/ERP/Financials integration, and clearing and settlement systems to > be business applications or do you limit that term to describe CRUD > processing? I don't want to get into another definition battle about what a "biz app" is. I generally deal with custom biz apps so I cannot say much about packaged biz apps such as SAP. If you claim DB's stink for SAP, I probably won't challenge it. If you want an example to reference and talk about, how about: http://c2.com/cgi/wiki?CampusExample Most degreed readers can relate to such an example fairly well because they've spent 4+ years at one. > > > > > Most non-trivial biz apps will be helped by a RDB. I have seen > > > > very few exceptions given. > > > > > > That's not the point under discussion. You asked why tables > > > don't model problem domains as well as OO constructs. That > > > question has been answered. > > > > Not. No specific scenarios given. > > If you feel the arguments presented by myself and, more > eloquently, Mr. Lahman unconvincing, please identify your specific > concerns. They don't provide specific demonstrations. They rely too heavily on fuzzy words and anecdotes. > Your rhetorical ploy of asking for scenarios that you will > then use to take the discussion down multiple ratholes is easily > recognized given your history and is no less disingenuous now than it > has ever been. I'm guilty until proven innocent? > > As Mr. Lahman has eloquently pointed out, only CRUD/USER > > applications map directly to the relational model. Other > > applications require different models of both data and behavior. > > Since SQL has a limited support for modeling behavior relative to > > general purpose languages, by your own admission, it is less capable > > of reflecting the abstractions of problem domains other than those > > of CRUD data pipelines. > > What objections do you have to that position? He is using the "thing must be potentially capable of being the whole app" definition of "general purpose". I have rejected that def of "general purpose" for reasons I don't want to repeat again regarding the "Yin-Yang" debate. > > > You are, I suspect deliberately, avoiding the point. You > > > asserted that all NFRs in an enterprise system could be met by > > > 'purchasing a "big-iron" RDBMS. > > > > I did NOT say ALL! My statement has been misrepresented here. > > Your exact words were: > > I would note that a lot of the issues you mentioned, such as > performance, scalability, resiliency, and recoverability can be > obtained by purchasing a "big-iron" RDBMS such as Oracle or DB2. > > In context, this is clearly a claim that performance, scalability, > resiliency, and recoverability can be provided to enterprise systems > solely through the use of Oracle or DB2. Anyone willing to look > through the thread will see that you were attempting to convey the > idea that big RDBMSs are all that is necessary to meet the needs of > enterprise systems. That's nonsense. Sorry, but I don't see anything that implies "all". Note "a lot of" in the opening sentence. Lot != All > > What is the difference? Just pick something that Kerbo does well and > > show why RDB/ACL's fail it. Why are you resisting? > > Since you clearly aren't interested in learning anything about > the topic you're embarrassing yourself about, even when pointers to > the documentation are provided, here is a quick summary for you. > > Kerberos is a service that allows mutual authentication between > users and services in a distributed system. By design, it avoids the > need to re-enter passwords for each interaction. What is important to > this discussion is the protocol. Simply having ACL information > accessible via a database provides no value against the threat models > addressed by Kerberos. > > Realize that this is just one set of security requirements > typically found in enterprise systems and you will see why your > statement that "security is mostly just massive ACL tables" is > laughable. That statement was a mistyping on my part, as already pointed out. It should have said, "security can be done with mostly just massive ACL tables". I was describing a scenario there, not meaning to paint the scenario as representative of everything. If you are claiming that ACL's cannot do "mutual authentication", then simply say so. Is that what you are claiming? > > Sincerely, > > Patrick > -T-
From: topmind on 2 Feb 2006 20:13
Dmitry A. Kazakov wrote: > On 1 Feb 2006 19:14:42 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 31 Jan 2006 19:36:38 -0800, topmind wrote: > >> > >>> Relational normalization is > >>> driven pretty much by avoiding duplication (at least the first 3 > >>> "laws"). OO tends to duplicate interface patterns such as add, change, > >>> delete, sort, etc. for each class. It does not factor similar "database > >>> verbs" into one spot, replicating them per class (with "creative" > >>> twists for each personality). And many-to-many in OO often results in > >>> two-way pointers. > >> > >> The difference is between one type and multiple types. Relational model > >> deals with *one* class: table. OO tries to handle more than one class. > >> Consider tables of types instead of tables of objects, and we'll see if > >> that will be any simpler. > > > > I don't believe in "types" as a useful model, at least not for my > > domain. > > That's up to you, but there is no any viable alternative. The point is that > the relational model is a particular case of more general typed model. Then > you aren't sincere. In SQL you are using types like integers, strings and > some others. If you didn't believe in them, then you should have replaced > them all with relations. Note that mathematically it is quite possible. Now > the question, why didn't you? Related discussion: http://c2.com/cgi/wiki?DoesRelationalRequireTypes The "expression engine" can be logically seperated from a relational engine it appears to me. As long as the expression engine supports equality comparisons (less than, equal, etc.), then relational can operate on it. (And possibly only just equal or not equal are needed. Need more pondering on this.) SQL is a specific language with certain constructs hard-wired in. However, SQL is not the end-all-be-all of relational nor query languages. Thus, if somebody wanted to include imaginary numbers in a relational query language, in theory they could without busting relational. It demands very little of the underlying expression model. > > > If I was forced to be an OO'er, I would probably take Smalltalk > > or Python over Java or Eiffle. > > They all are typed, as well as SQL. It is impossible to have a truly > untyped language. You might reduce it to a very narrow or singleton set of > types, but not further. There could only be well and poorly typed > languages. Well, this gets into a sticky issue of a definiton of types. Let me just put it this way: "a reduction of a reliance on types to model the domain". In other words, the language may have a few native "types" (functions, arrays, variables) to serve as the building blocks. However, one does not add new "types" to model the domain in such languages, rather using other approaches instead (schemas, functions, etc.). > > >>>>> Yes, mass repetative verbose static Set/Get's. > >>>> > >>>> There are bad languages, which don't fully implement ADT. So? > >>> > >>> Converting attribute-driven interfaces into ADT's is still pretty much > >>> Set/Get. > >> > >> They implement attribute access. It is up to the language to provide > >> X.Attribute notation rather than nasty X.Get_Attribute. I don't see any > >> problem here. > > > > For simple stuff it might be okay, but for more complicated stuff it > > turns into a Bachmanian navigational mess. For example, specifying > > many-to-many relationships. > > Between what an what? Again, with one table type you have > > X."Attribute" or (X."A1" and X."A2" and X."A3" ...) > > > instead of > > X.Attribute or (X.A1 and X.A2 and X,A3 ...) > > See what is different? Indirection? > > It is up to you to map things to types or to objects. There is no best > choice. In each concrete case the software designer shall reconsider it > anew. Well, if everything you are considering is an attribute, then you will have a kind of database anyhow, just a navigational one in your case. But that is not usually what is done, so it is only a speculative situation. > > >>>> What about inserting when no > >>>> row exists and updating otherwise? > >>> > >>> MySql has a command just for this. > >> > >> The advantage of ADT is that you can define that command and provide an > >> implementation for. SQL does not have proper ADT, otherwise people would do > >> higher-level programming directly in SQL. The methodology of higher-level > >> programming is OO. > > > > I can write a function to do the same thing. However, function > > interfaces to such are often not as flexible as query-based interfaces. > > How INSERT is different from user function? Why is it more flexible? Because SQL stinks in certain areas. And, there are cases where a procedural interface may be more appropriate than a declarative one. I don't dispute that. I never claimed SQL or relational was best for the *entire* app. Sometimes use Yin, sometimes Yang. > > > Ideally the query language would be extendable if a DBA etc. wanted to > > add an operation to it. However, SQL's excessively complex syntax makes > > such very difficult. SQL has some weak spots, I will agree. However, no > > standard is perfect and the current alternatives are net uglier. > > And the only good way to extend languages is by letting user to define > ADTs! [ In 60-70s there was a lot of extendable languages in the sense of > syntax-extensible. They all are gone, because programs were unreadable and > unmaintainable. ] There is a certain balance between standards and flexibility. Relational reigns in the some of "creativity" found in navigational structures, and this is usually a good thing. Sure, there are side-effects that can be annoying, but it is the net benefits that count. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T- |