SQL
in [OOP]
|
From: topmind on 31 Jan 2006 22:43 Alfredo Novoa wrote: > 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. TC generally makes virus-writing easier. For example, there are more JavaScript viruses than HTML viruses. -T-
From: topmind on 31 Jan 2006 22:53 > SQL - which I beleive was backronymed as 'Structured Query Language' - > certainly _is_ a query language at its core. Recent versions of the SQL > standard have bolted on standardized versions of previously > database-vendor-specific extensions, such as stores procedures, triggers, > a turing-complete extension language for those stored procedures and > triggers; but none of that is part of the core of what a database does. > > There's a reason why all these bolt-ons have materialized: database engine > vendors are unhappy with their product being seen as a storage solution, > which is what it fundamentally is; so they have added these extensions in > order to allow much code that doesn't have anything with the database per > se, into the database engine's confines - precisely such things as stored > procedures and triggers and so on. > > I think everybody agrees that enforcing business rules is a good thing. > You, however, proclaim that this needs to be done _in the database > engine_ - and then argue that in order to support this, the database > engine must include its sturing-complete extensions, because otherwise you > mau not be able to express all the business rules. But that's really > circular reasoning: If you left all the extensions off the database > engine, and used it just for its core purpose - storing data ans making > available for access - all the validation can be done in code that liveds > happily outside the database. So, the 'need' for turing-complete > extensions to databases only arises when one starts from the premise that > business logic should be implemented in the database; but that premise is > one that can only be used if there exist sufficient facilities > (turing-complete extensions) alongside the database's core functionality > in the database engine. >From a practicality standpoint, business rules/logic should only be in the DB if they are truly "global" and likely to stay that way. Application or task-specific biz logic behavioral code generally does not belong there IMO. In other words, use it to enforce integrity, not to write apps. Some shops stuff everything into SP's for the hell of it. They sometimes claim it makes things run signif faster, but it can be a maintenance headache. Only put the most commonly-used ones in SPs if you need the speed. (Of course there are exceptions where speed has been determined far more important than development/maint costs.) -T-
From: Dmitry A. Kazakov on 1 Feb 2006 10:32 On 31 Jan 2006 19:36:38 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> There are many clean and consistent things, which lead to a total mess when >> used inappropriately. DB applications represent an excellent example. > > True, but OO has no consistent "right way". As well as programming in general. > 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. >>> 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. >> 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. >>>>>> Similarly, just because different object-oriented programming languages >>>>>> may have problemsinteroperating with each other's objects, isn't a failing >>>>>> of object-orientation. >>>>> >>>>> Non-OOP protocols are usually easier to share. >>>> >>>> True, when they are low-level. >>> >>> I disagree. Please justify. >> >> Consider machine code as a protocol. Why would you like to have any >> programming language instead? > > I don't know what you are implying. Perhaps an example would help. Isn't machine code a simple communication protocol to CPU? You send the code of MOV and CPU does that. Simple? Can you handle it without a compiler? Protocol must match the complexity of what you want to tell to the receiver. Simplicity alone isn't an advantage. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Patrick May on 1 Feb 2006 17:04 "topmind" <topmind(a)technologist.com> writes: > > > > 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. > > > 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?" My most recent projects include mobile telco OSS, integration of a number of disparate, geographically distributed MRP/ERP systems with an enterprise-wide financials system, and a clearing and settlement system for a major bank. I consider all of these to be business applications, and all are considerably more complex than CRUD/USER 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. > > Where is your evidence that proliferation of accessors and > > mutators is generally accepted as good OO practice? > > I have seen debates where a fair amount of participants held such > view, such as usenet and c2.com. You can find people holding a wide variety of views on Usenet and Wikis. The fact that people make their writing publicly available doesn't imbue it with any particular gravitas. You need look no further than http://oop.ismad.com for an example of the errant nonsense that some people will spew. > Also Betrand Meyer spends a fair amount of text devoted to this > subject in OOSC2 such that he talks about language features to make > it easier to swap between "naked" values and accessors/muts when > needed so that one did not have to pick one side or the other > up-front. OOSC2 was considered a key OO work for several years. If Meyer claimed that violation of encapsulation via extensive use of accessors and mutators is a good idea, produce a cite. Otherwise, your claim remains unfounded. > > While we're on the topic of you producing evidence for your > > claims, here's a couple from this thread you still haven't > > supported: > > Most of them are informal side-issues I don't care to discuss right > now. 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? > > > Are you saying your techniques better fit with legacy systems? > > > > I am saying that your claim is nonsense. Given the need to > > integrate legacy systems and third party products, to expose > > business functionality to a variety of other business systems, to > > orchestrate various levels of processes and workflows, and meet > > all the other requirements of enterprise systems, the idea that > > the NFRs can be met 'by purchasing a "big-iron" RDBMS' is > > ridiculous. > > I would like a code demo on how non-RDBMS better fit legacy systems. 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. That claim is utter nonsense, for the reasons I've detailed in this thread among many others. Either back up your position or retract it. > > > > I'll type more slowly. There is no mention of ACLs in > > > > the references I provided. The references I provided show how > > > > some important security issues are addressed. This > > > > demonstrates that your claim that '"Security" is mostly just > > > > massive ACL tables.' is nonsense. > > > > > > Okay, I see where this went wrong. I meant security *could* be > > > implemented by massive ACL tables. > > > > No, it cannot. Either you really don't understand this, in > > which case you should not be commenting on the topic, or > > Mr. Lahman is correct and you are deliberately attempting to annoy > > people who do know something about the issue. > > > > ACLs stored in database tables don't even begin to address > > the security needs of large systems. Read the references > > provided. > > All you have to do is give a realistic and fairly common example of > where RDB ACL's fail. 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. Further, this is just one example of security requirements for enterprise systems. I've provided you with pointers to the documentation. If you read and understood it, you'd realize that your request is nonsensical. 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 1 Feb 2006 21:39
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > > > 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. > > > > > > 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?" > > My most recent projects include mobile telco OSS, integration of > a number of disparate, geographically distributed MRP/ERP systems with > an enterprise-wide financials system, and a clearing and settlement > system for a major bank. I consider all of these to be business > applications, and all are considerably more complex than CRUD/USER > processing. 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. Note that I don't claim that RDBS are to be the whole enchilada. They are a primary tool, perhaps the biggest tool, but are not expected to do everything an app needs. > > > 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. [Deleted mutator issues. Mutators immaterial to this discussion] > > > While we're on the topic of you producing evidence for your > > > claims, here's a couple from this thread you still haven't > > > supported: > > > > Most of them are informal side-issues I don't care to discuss right > > now. > > 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. > > > > > Are you saying your techniques better fit with legacy systems? > > > > > > I am saying that your claim is nonsense. Given the need to > > > integrate legacy systems and third party products, to expose > > > business functionality to a variety of other business systems, to > > > orchestrate various levels of processes and workflows, and meet > > > all the other requirements of enterprise systems, the idea that > > > the NFRs can be met 'by purchasing a "big-iron" RDBMS' is > > > ridiculous. > > > > I would like a code demo on how non-RDBMS better fit legacy systems. > > 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. > That claim is utter nonsense, for the > reasons I've detailed in this thread among many others. Either back > up your position or retract it. You have not presented sufficent failure scenarios for RDBs to show they are a minority tool. Yes, they don't do embedded apps, scientific calculations, or free-form text search very well, but that is not the majority of most biz apps. > > > > > > I'll type more slowly. There is no mention of ACLs in > > > > > the references I provided. The references I provided show how > > > > > some important security issues are addressed. This > > > > > demonstrates that your claim that '"Security" is mostly just > > > > > massive ACL tables.' is nonsense. > > > > > > > > Okay, I see where this went wrong. I meant security *could* be > > > > implemented by massive ACL tables. > > > > > > No, it cannot. Either you really don't understand this, in > > > which case you should not be commenting on the topic, or > > > Mr. Lahman is correct and you are deliberately attempting to annoy > > > people who do know something about the issue. > > > > > > ACLs stored in database tables don't even begin to address > > > the security needs of large systems. Read the references > > > provided. > > > > All you have to do is give a realistic and fairly common example of > > where RDB ACL's fail. > > 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? > Further, this is just one example of security requirements > for enterprise systems. > > I've provided you with pointers to the documentation. If you > read and understood it, you'd realize that your request is > nonsensical. You complained when I said that Meyer's accessor complaints were "somewhere in his book", yet expect me to accept the *same thing* from you. You can't just drop a bunch of manuals in somebody's lap and make them hunt for YOUR evidence. If you cannot provide *specific* failure or trouble scenerios, then we cannot go any further with this debate. If you say they are not necessary, I disagree. I am tired of debating about debating here. I would rather fiddle and ponder technical ideas but that cannot be done that I see without (at least) specific scenarios. > > Sincerely, > > Patrick > -T- |