SQL
in [OOP]
|
From: topmind on 5 Feb 2006 15:28 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > 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. > > This is a complete non sequitur. I honestly have no idea what > you mean by your term "biz apps." Rational discussion depends on > well-defined terms. Well, actually it turns out that the "tough" problems are tied to inharently fuzzy terms. The definition of "life" is even contentious and there are plenty of border disputes. However, hopefully we can find ways to work around fuzzy distinctions. > When you say "I generally deal with custom biz > apps", do you mean "I generally work on CRUD data pipelines"? If not, > do you consider OSSs, MRP/ERP/Financials integration, and clearing and > settlement systems to be business applications? I made a distinction between *custom* biz apps and packaged apps. The needs of packaged apps may be different than custom ones because change impact may impact 1000 companies instead of just one. Thus, tools that ensure accuracy and verification may be far more important than the budget of the change effort, giving them a very different development flavor that single-company apps. > > > > > > 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. > > I see nothing fuzzy in Mr. Lahman's summary that 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, This is misleading. Not being TC does not make it non-general-purpose. You are comparing apples to oranges. We have been over this already with the "hammer" debate. > it is less capable of reflecting the > abstractions of problem domains other than those of CRUD data > pipelines. To perhaps oversimplify, the difference is this: OOP is fair at behavior management and somwhat crappy at attribute management, while relational is great at attribute management but crappy at behavioral management. The difference is that one does not usually *expect* relational to carry the WHOLE LOAD, unlike many OOP proponents for OO. You keep trying to frame this debate in doing the whole thing from end-to-end. That is a misleading definition game. Knock it off. In short, you are trying to view relational through OO-colored glasses. OO'ers generally expect (or hope) a single language and paradigm to be the entire app. > > This position, with which I agree, does not require specific > scenarios. It deals with the concepts underlying the relational model > and general purpose languages. What are your specific disagreements > or points of confusion? You know what they are. > > > > 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? > > No, you're guilty by reason of your behavior on this newsgroup > over the past years. Such as not providing code evidence that OOP is objectively better for custom biz apps? Oooops, that is your sin, not mine. > > > > 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. > > No, he is explaining why the relational approach is more limited > in modeling than are general purpose languages. Apparently you agree > since you recognize that a pure relational design cannot meet all > system requirements. If you are going to insist that relational *be* the entire app, by that definition you have technically won. I am not comparing them that way. I am using the Yin-Yang model. You have not shown relational objectively worse under the Yin-Yang model. > > > > 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. > > As I said, in context it was clear what you were claiming. While > you did not say that a big-iron database could meet all NFRs, you > specifically included performance, scalability, resiliency, and > recoverability as NFRs that could be met by such a database. I have > shown that position to be untenable. Not. You only claimed it. You have NOT provided a specific failure scenario and I will not take anything less as evidence. > > > > 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? > > As I have repeatedly said throughout this thread, That is ALL you do: repeatedly say. Repeat after me: SHOW SHOW SHOW SHOW. > the > functionality provided by Kerberos cannot be provided simply through > the use of ACLs. Talk is cheap. > Further, this functionality is just one small subset > of the security requirements of enterprise systems. Thus, even your > amended claim is nonsense. > > Show how "massive ACL tables" can provide the functionality > provided by Kerberos or admit that your claim is bogus. I am not going to clone entire Kerberos just to disprove your point. That is an unrealistic expectation. You are being silly, Bub. It would be far easier for you to supply a scenario where ACL/relational flops. Why can't you provide that? It does not require 300 pages of documents or 30,000 lines of code. At least give a decent justification of why you cannot provide such. > > Sincerely, > > Patrick > -T-
From: Patrick May on 5 Feb 2006 16:50 "topmind" <topmind(a)technologist.com> writes: > > When you say "I generally deal with custom biz apps", do you mean > > "I generally work on CRUD data pipelines"? If not, do you > > consider OSSs, MRP/ERP/Financials integration, and clearing and > > settlement systems to be business applications? > > I made a distinction between *custom* biz apps and packaged > apps. The OSSs, integration projects, and clearing and settlement system I've recently developed are all custom work. Do those systems fall under your definition of "custom biz apps" or do you reserve that term as a synonym for "CRUD data pipelines?" > > This position, with which I agree, does not require specific > > scenarios. It deals with the concepts underlying the relational > > model and general purpose languages. What are your specific > > disagreements or points of confusion? > > You know what they are. No, I don't. You have not articulated them. You are asking for examples when the argument not only does not require them but cannot benefit from them. By your own admission, the relational approach must be complemented by an alternative paradigm in order to fulfill the requirements of real systems. Other approaches, be they object oriented, imperative, functional, or some combination or extension thereof, can model the full problem domain. That's the entire point of disagreement here. You seem to be saying on one hand that the relational approach is equally capable of modelling problem domains while on the other hand admitting that it must be supplemented with different techniques. That's a contradiction. > > > > 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. > > > > No, he is explaining why the relational approach is more > > limited in modeling than are general purpose languages. > > Apparently you agree since you recognize that a pure relational > > design cannot meet all system requirements. > > If you are going to insist that relational *be* the entire app, by that > definition you have technically won. Hail Eris, we can put a bullet in the head of this topic. > I am not comparing them that way. I am using the Yin-Yang > model. You have not shown relational objectively worse under the > Yin-Yang model. You're renaming the combination of relational and one or more additional approaches to be "relational." When you change the meaning of your terms like that, mid-discussion, it makes rational interaction impossible and gives every appearance that you would rather knowingly equivocate than admit that you were wrong. > > As I said, in context it was clear what you were claiming. > > While you did not say that a big-iron database could meet all > > NFRs, you specifically included performance, scalability, > > resiliency, and recoverability as NFRs that could be met by such a > > database. I have shown that position to be untenable. > > Not. You only claimed it. You have NOT provided a specific failure > scenario and I will not take anything less as evidence. Read back through the thread. The need to integrate legacy systems and off-the-shelf applications so that they work together in an enterprise environment means that simply using a big-iron database will not meet the NFRs of performance, scalability, resiliency, and recoverability. Your claim that it could is clearly nonsensical. > > > > 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. > > > > > > If you are claiming that ACL's cannot do "mutual > > > authentication", then simply say so. Is that what you are > > > claiming? > > > > As I have repeatedly said throughout this thread, > > That is ALL you do: repeatedly say. Repeat after me: SHOW SHOW SHOW > SHOW. You are a liar. I provided pointers to the documentation on Kerberos and, when you demonstrated a continual refusal to read that documentation, summarized it for you. All of the examples you (or, rather, an intellectually honest person) could require is in those documents. > > the functionality provided by Kerberos cannot be provided simply > > through the use of ACLs. > > Talk is cheap. Not talk, proof. ACLs stored in databases are just data. Kerberos is about implementing security policies and procedures that meet well-specified usability requirements and threat models. A rational, competent software developer would easily see this after reading the referenced documentation. Whether you do or not is clearly a different question. > > Show how "massive ACL tables" can provide the functionality > > provided by Kerberos or admit that your claim is bogus. > > I am not going to clone entire Kerberos just to disprove your point. > That is an unrealistic expectation. You are being silly, Bub. You don't need to clone the entire thing. You just need to show how the functionality could just as easily be provided by ACLs. If you understood security in general or Kerberos in particular, you'd realize how ridiculous your claim is. > It would be far easier for you to supply a scenario where > ACL/relational flops. First of all, as I detailed previously, it isn't a matter of "relational flopping", it's that simple database tables cannot provide the functionality of Kerberos. It's like asking for an example of where a pick-up truck is a bad tool for placing girders when building a skyscraper. Your question doesn't even make sense; it serves merely to show how limited your understanding of the domain is. Secondly, I have provided the necessary information for you to understand why your claim is foolish, you just refuse to read the documentation. Sincerely, Patrick P.S. Your continued silence regarding your unsubstantiated claims is not unnoticed. ------------------------------------------------------------------------ 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 5 Feb 2006 17:00 Dmitry A. Kazakov wrote: > On 4 Feb 2006 15:28:10 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 3 Feb 2006 18:28:11 -0800, topmind wrote: > >> > >>> Well, like I already said, I am not sure relational requires ordering > >>> either. If ordering is a pivotable issue for your claim, then let's > >>> explore it further. > >> > >> You still need: > >> > >> 1. "=", an equality relation (transitive, symmetric, reflexive) > >> 2. Copy constructor, to have an ability to place things into cells > >> > >> The above is interface of a copyable, comparable type. > > > > Having the ability to be copyable and comparable does not *make* it a > > "type", unless you are using a very loose definition of "type". It > > indeed may be possible to view everything as a type. But that does not > > necessarily make everything actually *be* types. > > It is a language issue then. The point is that relational model, you refer > to, can be fully described in terms of types, and therefore represent not > an alternative, but just a case. Perhaps. There may be other and perhaps better "everything is a" viewpoints that are pretty much interchangable with each other. I remember some guy claiming that "everything is a closure". But just because you can does not mean you should. > > >>> I agree that ADT's are pretty good for systems software (although sys > >>> soft. is not my specialty, I should note). However, the concepts don't > >>> appear to apply to well to business modeling. An RDBMS engine that may > >>> be designed such that the "expression engine" (for lack of a better > >>> name) can be swapped without changing the relational engine may indeed > >>> use many ADT concepts. > >> > >> Same for business, same for any other modeling. Don't some biz-models have > >> something in common, more advanced/specific than just relations? If so, > >> then those can be extracted in a form of a "biz engine", more specialized > >> than general "expression engine". ADTs just gives you a tool for doing such > >> things. > > > > As I have said many times, in the real world the patterns of > > differences/changes are not hierarchical. The variations of things tend > > to be a semi-random selection of all possible combinations of factors > > (Cartesian join). I find sets better able to handle such differences > > than hierarchies. "Types" are too tied to the idea of "is-a", when mass > > "has-a" management is more appropriate for variation management. > > I have answered this. If you can map relations to individual objects rather > than types, do it. Nobody proposes to invent types where unnecessary. A > program with a lesser number of types is easier to understand. The problem > is that quite often this is technically impossible. If you wish to force > everything into the limited set of types, SQL has, you must also accept > much higher developing costs and maintenance beyond anyone's capacity. When I see an actual case with code from my domain, I might change my mind. Types don't model biz things very well IMO. A viewpoint one needs tends to be relative, and types don't handle that very well, wanting a universal classification instead. "Encapsulation" generally does not allow for overlaps. Set theory does. > > >> For "add" to report "not a number" means that it should know the types of > >> the operands. This means that you need types at least to check them. > > > > How specificly is "types" different from "validation" in this example? > > > > x = add("123","99.28"); > > y = add("foo","7"); > > > > The language does not care what "foo" is here. Only the "add" function > > will care when it checks to see that the first parameter is a valid > > number. > > The above isn't properly typed. "123" has the type String. Strings aren't > additive. Language can and do this. Label it however you want, it works. > > > There are other things it might check such as range because it > > may not be able to add large numbers. Types cannot do this very well > > unless we either pick arbitrary chunk sizes, or create a type for every > > possible length/size, which is dumb. > > Types do it perfectly. I can have a wide set of numeric types having > different models. And long-winded confusing code to use it. > It is a very important issue. Numeric types are models > and there could be many different models of integer, real and other numbers > as found in mathematics. Note that range is only one aspect here. There is > also precision, rounding, accuracy of numeric operations etc. Further typed > systems describe requirements on the type and the compiler/engine is > responsible to fulfill these requirements *automatically*. This way is far > more safe than adding "123" to "99.28", riddling if the result is > "12399.28". The "protection" of heavy typing is not free. Often it requires twice as much code as type-free code and longer coding time. With a type-free language one can use the time left over from brevity and clearity to spend on testing, unit tests, etc. Type-free code reads more like psuedo-code. Type-heavy code reads like legalese. Businesses are run by scrooges: they want productivity at a low cost. Strong typing does not provide this. It may perhaps provide a high degree of accuracy if the resources are provided to spend on the bloated red-tape typish code, but companies don't want to spend that. They will tolerate slightly more errors if the cost is a lot lower. Plus, the errors caused by not understanding the customer or the domain are often a bigger component than outright program errors. It is usually cheaper to educate a few good "scripters" in the domain than an army of precision strong typers. But, there are areas where the reverse might be true, such as life-support medical equipment. > > >>> Again, I would like to see a specific scenario of OO outdoing RDBS in a > >>> custom biz app setting (outside of machine performance issues for now). > >> > >> Technological changes don't happen over night. Then there are serious > >> issues of foundations and lack of properly typed languages. I can't predict > >> what would a typical biz application do in 10 years. > > > > I am not here to argue the merits of strong/weak/none typing. (Unless, > > perhaps you are one who thinks OO == Types.) > > OO <= Types First you would have to form a clear, consensus definition of OO to prove this. Good luck with that task. > > >> but also utterly inefficient with respect of > >> space and time required for may operations. > > > > When I encounter enough of such scenarios, > > Put an image in relational table, so that each pixel would be a cell. > Put a program code in a relational table and write compiler in SQL > ... Why SQL? SQL is one of an infinite possible relational languages. Further, one does not have to actually store stuff in a physical grid in RAM or disk (if there is such a thing). And, how would making each pixel an ADT or Object improve the picture (pun)? > > > Further, relational does not dictate implementation. > > Wrong, it puts definite limits of the implementation. Show me a definite limit. > > > If I am *searching* based on multiple factors, sure I'd be happy to use > > a (good) table browser. > > That's the point, you need a different paradigm, because "path" is not a > type in SQL. Because result sets aren't ordered in SQL, etc. Write a GPS > car navigation system representing the results as relations and try to sell > it *anybody*! Please clarify. BTW, here is a "road" schema: Table: Road ----------- roadID roadTitle roadType (Highway, Main, Side, Mixed, etc.) Table: Points ------------- pointID Longit (longitude) Lattit (lattitude) Table: RoadSegment ------------------- roadRef (references roadID) segID (may not be needed) fromPoint (reference Point table) toPoint segmentType (Highway, Main, Side, etc.) There are other, perhaps better, ways to do this. I added a "Point" table so intersection info may be easier to represent. This is just a quickie demo. > > > Further, I find dynamic or type-free systems more adaptable to multiple > > languages and tools. Compile-time-checking tends to assume the whole > > world is the same language and gag when it isn't. RDBMS info has proven > > more sharable than Java, Eiffle, etc. > > It isn't static vs. dynamic. Time of checking is so far irrelevant. As long > as 23 has only one type, there is nothing to check. > > >> The problem of gotos is their power. They have too big "norm". > >> Mathematically, small program changes may lead to an enormous, > >> unpredictable effects. > > > > Goto fans might argue that the impact of change is only unpredictable > > to those who don't "get" goto's. > > There are not so many goto's fans left. Same with RDBMS, they are already > extinct, and coming generations will forget about them. Sorry, I see no evidence of their demise. Commercial sales are down a bit of late, but this is probably because open-source solutions are coming of age. The only current threat seems to be OO'ers who want to do more in Java etc. and less in SQL. However, that battle is still raging with no clear winner. One of the biggest selling points of RDBMS is that multiple languages can use them. I've seen Oracle systems that lived through COBOL and are now having web languages, MS-Access, and languages like Java all hooked to the *same* DB. Until you find a way to make OO/ADT results or access more sharable, this aspect alone will keep them around for practical purposes. > > >> That is the fate of programming as a whole. > >> Relational approach suffers it very much. Just consider joins. The beauty > >> of specialized domain languages is not their power, but, on contrary, lack > >> of power - there is much less you can do wrong. > > > > Huh? If everybody invents their own join, how does that reign in > > problems? > > Should any problem be solved in terms of joins? You are trying to sell me a > wrong tool! I never said that. I am only saying that a lot of stuff that some view as "domain specific" are simply database-like activities disquised as domain-specific issues. They are largely reinventing the wheel without knowing it. I will make domain-specific functions when needed, I would note. Using RDBMS does not prevent this. Sometimes I even mix them to get the best of both: doProcessFoo(123, bar, "x > 3 and y='blah'"); [...] function doProcessFoo(id, glog, clause) {.......} Here I pass in a WHERE-clause expression. (Some consider this a security risk do to potential "sql-injection", but it is usually for narrow-use intranets where much of the key data is read-only anyhow under the logins used by the app.) > > >> OO as a paradigm and ADT as its vehicle tries to keep the power, but also > >> provide checks and balances to diminish negative impact of exercising that > >> power. In particular, discipline in OO is enforced on the component basis. > > > > Show with code. > > But you said that you aren't interested in static program correctness > analysis. > > If you want a challenge, fine. Take any machine learning method. Training > sets are ideal tables, rows and columns, nothing else. Take any method of > your choice and implement it in SQL! For introduction to existing methods, > see excellent tutorials by Andrew Moor: > > http://www.autonlab.org/tutorials/ How about something from the domain of custom biz apps. I have already conceded out of ignorance of the domain that DB's may not be good for heavy-duty numerical analysis. > > You have *pure* relational data. Note that whole machine learning is > nothing but just SELECT training_set WHEN example=x. So, don't hesitate, > give me a Support Vector Machine in SQL! > > >>> Outside of specific languages or implementation, the two biggest > >>> differences between relational and OO are: > >>> > >>> 1. Each "record/map" must belong to one and only one entity (table) in > >>> relational. OO's "map" has no such restriction. Inheritance can emulate > >>> such, but that is optional. Each object can float independently. > >> > >> Do you refer to singletons here? I don't see why this should be essential, > >> but it is no problem to enforce that in an OOPL. Make constructors private, > >> if you want, and here you are. But as a principle, it is wrong - numbers, > >> strings aren't bound by this rule. 123 can be in any number of cells. Try > >> to consider a wider picture: there are things in cells, cells themselves, > >> rows, columns, tables, sets of tables, sets of sets of tables etc. ADT > >> offers you a unified way to handle that all. > > > > No, it does not. ADT by itself is not a language and relational is a > > bigger picture than ADT's. > > Come on! SQL can be trivially described in ADT's. Try the opposite. Just > place a table into another table, flip a table column, describe a ring in > SQL, write a task scheduler in SQL... Again, I don't expect SQL or relational to solve the *entire* problem by itself. Remember the Yin-Yang debate? A good case that a Yang-only system is inharently better was not made. > > >>> 2. Relational generally assumes a partitioning between data and > >>> behavior, while OO tries to meld them. > >> > >> Actually it tries to get rid of data. It says that there is no data, but > >> only behavior. The rationale is as follows. You cannot perceive data, only > >> the behavior of those. This is in full accordance with mathematics. There > >> is no such thing as number 123. There is a set of properties it and similar > >> things expose. Moreover, try to ask yourself what is a relation, and you > >> will see that a pure relational approach should care about data even less. > > > > Well, data and behavior are just different views of the same thing. > > Can you name this thing? Again, what is a relation? Formulate it, and point > me the word "data". No, I cannot name "it". When we start modeling things that don't exist in the real world, English is often no longer sufficient. But to give an analogy, program code is merely data to the interpreter/compiler. A developer may think of a function as "behavior", but the interpreter treats it more like data if we look at other processes that read what we normally call "data". It is yet another case of relativism where "is-a" flunks. > > > This would get into a definition battle that has no hard math to say > > yeah or neah. > > One thing is quite clear, it is impossible even to define the term "data", > without description of behavior. Look at mathematical definitions of > numbers. > > "Data" is a set of computation states, characterized by definite behavior. Perhaps you should make a distinction between "is a set of" and "can be defined as a set of". Claiming something "is" is a strong ascertion. > When it is said that a table cell contains 1, it means all states where Get > (or SELECT) would deliver result associated with the application domain > object denoted as 1. > > It is the behavioral approach, which makes both OO and your beloved > relational model *implementation-independent*. Otherwise, you were unable > even to talk about "data", because, again, what in common have two states > of magnetic fields on the hard drives of two computers? They expose same > *behavior*, which you call "data"! Is big-endian and low-endian encoded > 26732147 same "data"? Perhaps, but that is an implemention issue. There may be other ways to implement it. > > -- > Regards, > Dmitry A. Kazakov -T-
From: topmind on 5 Feb 2006 17:30 Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > > When you say "I generally deal with custom biz apps", do you mean > > > "I generally work on CRUD data pipelines"? If not, do you > > > consider OSSs, MRP/ERP/Financials integration, and clearing and > > > settlement systems to be business applications? > > > > I made a distinction between *custom* biz apps and packaged > > apps. > > The OSSs, integration projects, and clearing and settlement > system I've recently developed are all custom work. Do those systems > fall under your definition of "custom biz apps" or do you reserve that > term as a synonym for "CRUD data pipelines?" They probably are considered "biz apps", but I would like more detail. By the way, what is wrong with using the previously mentioned "Campus" example here for comparing? I already described why I feel it is probably a good public comparison example. > > > > This position, with which I agree, does not require specific > > > scenarios. It deals with the concepts underlying the relational > > > model and general purpose languages. What are your specific > > > disagreements or points of confusion? > > > > You know what they are. > > No, I don't. You have not articulated them. You are asking for > examples when the argument not only does not require them but cannot > benefit from them. Huh? Almost everything is helped by examples. > By your own admission, the relational approach > must be complemented by an alternative paradigm in order to fulfill > the requirements of real systems. Agreed. > Other approaches, be they object > oriented, imperative, functional, or some combination or extension > thereof, can model the full problem domain. Agreed. > That's the entire point > of disagreement here. You seem to be saying on one hand that the > relational approach is equally capable of modelling problem domains > while on the other hand admitting that it must be supplemented with > different techniques. That's a contradiction. It is only a "fault" if the net advantages are less than the single-tool approach. All else being equal, perhaps a single-tool approach would be preferred. However, specialization is common in society and economics, so it makes sense to consider for software also. You have not made a good case for specialization being evil. I agree singleness will make certain things simpler, but not everything simpler. > > > > > > 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. > > > > > > No, he is explaining why the relational approach is more > > > limited in modeling than are general purpose languages. > > > Apparently you agree since you recognize that a pure relational > > > design cannot meet all system requirements. > > > > If you are going to insist that relational *be* the entire app, by that > > definition you have technically won. > > Hail Eris, we can put a bullet in the head of this topic. So we should end specialization in economics also? Every farmer also be a nuclear physiscst? (I hate spelling that word) > > > I am not comparing them that way. I am using the Yin-Yang > > model. You have not shown relational objectively worse under the > > Yin-Yang model. > > You're renaming the combination of relational and one or more > additional approaches to be "relational." When you change the meaning > of your terms like that, mid-discussion, it makes rational interaction > impossible and gives every appearance that you would rather knowingly > equivocate than admit that you were wrong. This is why I wish to move to an example and scenarios. I feel we have stretched the linguistic approach to evidence as far as we can. > > > > As I said, in context it was clear what you were claiming. > > > While you did not say that a big-iron database could meet all > > > NFRs, you specifically included performance, scalability, > > > resiliency, and recoverability as NFRs that could be met by such a > > > database. I have shown that position to be untenable. > > > > Not. You only claimed it. You have NOT provided a specific failure > > scenario and I will not take anything less as evidence. > > Read back through the thread. The need to integrate legacy > systems and off-the-shelf applications so that they work together in > an enterprise environment means that simply using a big-iron database > will not meet the NFRs of performance, scalability, resiliency, and > recoverability. Your claim that it could is clearly nonsensical. You have not provided a specific failure scenario. > > > > > > 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. > > > > > > > > If you are claiming that ACL's cannot do "mutual > > > > authentication", then simply say so. Is that what you are > > > > claiming? > > > > > > As I have repeatedly said throughout this thread, > > > > That is ALL you do: repeatedly say. Repeat after me: SHOW SHOW SHOW > > SHOW. > > You are a liar. I provided pointers to the documentation on > Kerberos and, when you demonstrated a continual refusal to read that > documentation, summarized it for you. All of the examples you (or, > rather, an intellectually honest person) could require is in those > documents. Don't point, paste. (along with citation such as page number, etc.) Plus, showing that Kubi can do X does not mean that other approaches *cannot* also do X. What I reasonably expect is something like: Here is Kubie doing X well: a;lsdfjal;skd asddfaslkdjflaskfksadf asdflksjdf Here is relational ACL's doing it poorly: adf;asjdflkasdfd asdfdl;kasjdflkasddf asdflkjasdlf Here is how we measure "poorly": asdfasdassdf adflkajsdf;lkjsd asdfasdf asdflkasdflkkasjd That is a reasonable and common way to show how something can't handle something. > > > > the functionality provided by Kerberos cannot be provided simply > > > through the use of ACLs. > > > > Talk is cheap. > > Not talk, proof. ACLs stored in databases are just data. > Kerberos is about implementing security policies and procedures that > meet well-specified usability requirements and threat models. A > rational, competent software developer would easily see this after > reading the referenced documentation. Whether you do or not is > clearly a different question. Okay, is this back to the "relational can't do the whole thing by itself" issue? > > > > Show how "massive ACL tables" can provide the functionality > > > provided by Kerberos or admit that your claim is bogus. > > > > I am not going to clone entire Kerberos just to disprove your point. > > That is an unrealistic expectation. You are being silly, Bub. > > You don't need to clone the entire thing. You just need to show > how the functionality could just as easily be provided by ACLs. What do you consider "show"? > If > you understood security in general or Kerberos in particular, you'd > realize how ridiculous your claim is. Provide a specific scenario, and I will give it a whirl. > > > It would be far easier for you to supply a scenario where > > ACL/relational flops. > > First of all, as I detailed previously, it isn't a matter of > "relational flopping", it's that simple database tables cannot provide > the functionality of Kerberos. It's like asking for an example of > where a pick-up truck is a bad tool for placing girders when building > a skyscraper. You drop a girder on it and watch it go FLAT. If that is too expensive, then model one in a physics simulator. If the other party disputes the simulation, then at least there is something specific to compare and analyze. BTW, are you suggesting that DB ACL's fail for performance reasons or software management reasons? > Your question doesn't even make sense; it serves merely > to show how limited your understanding of the domain is. Not making sense (to you) and being evidence of naivity is not necessarily the same thing. Your interpretation of my alleged mistakes always has the worst possible interpretation with you it seems. It is antibenefit of the doubt. Grow some diplomacy skills. > > Secondly, I have provided the necessary information for you to > understand why your claim is foolish, you just refuse to read the > documentation. It is your job to present specific evidence to the jury, not dump a bunch of documents in their lap. If you don't have the skills to compress your case into something that does not need 300 pages, then you deserve to lose. > > Sincerely, > > Patrick > -T-
From: Dmitry A. Kazakov on 6 Feb 2006 13:59
On 5 Feb 2006 14:00:22 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> I have answered this. If you can map relations to individual objects rather >> than types, do it. Nobody proposes to invent types where unnecessary. A >> program with a lesser number of types is easier to understand. The problem >> is that quite often this is technically impossible. If you wish to force >> everything into the limited set of types, SQL has, you must also accept >> much higher developing costs and maintenance beyond anyone's capacity. > > When I see an actual case with code from my domain, I might change my > mind. Types don't model biz things very well IMO. They need not to. The whole point is that relational is typed as well. Full stop. Whatever advantages of modern typed systems could be used to improve (sic!) existing typed (sic!) relational systems is another question. It is up to developers. >>> How specificly is "types" different from "validation" in this example? >>> >>> x = add("123","99.28"); >>> y = add("foo","7"); >>> >>> The language does not care what "foo" is here. Only the "add" function >>> will care when it checks to see that the first parameter is a valid >>> number. >> >> The above isn't properly typed. "123" has the type String. Strings aren't >> additive. > > Language can and do this. Label it however you want, it works. Really? What is the result of add("fee", "123") ? "1069"? "4201"? "fee123"? "sysadmin(a)error.org"? >>> There are other things it might check such as range because it >>> may not be able to add large numbers. Types cannot do this very well >>> unless we either pick arbitrary chunk sizes, or create a type for every >>> possible length/size, which is dumb. >> >> Types do it perfectly. I can have a wide set of numeric types having >> different models. > > And long-winded confusing code to use it. Huh, the code you presented is 1) longer, 2) far more confused. >> It is a very important issue. Numeric types are models >> and there could be many different models of integer, real and other numbers >> as found in mathematics. Note that range is only one aspect here. There is >> also precision, rounding, accuracy of numeric operations etc. Further typed >> systems describe requirements on the type and the compiler/engine is >> responsible to fulfill these requirements *automatically*. This way is far >> more safe than adding "123" to "99.28", riddling if the result is >> "12399.28". > > The "protection" of heavy typing is not free. Often it requires twice > as much code as type-free code and longer coding time. With a type-free > language one can use the time left over from brevity and clearity to > spend on testing, unit tests, etc. Type-free code reads more like > psuedo-code. Type-heavy code reads like legalese. As I have shown, it is not type free. It is typed in a definite way. How do you know that this way is the proper one? Do you have use-tests to verify that? Did you count all these tests? Where are use tests for accuracy, rounding errors? > Businesses are run by scrooges: they want productivity at a low cost. I'm sure, they know pretty well what risk management is. > Strong typing does not provide this. SQL is typed, so I see no point. >>>> but also utterly inefficient with respect of >>>> space and time required for may operations. >>> >>> When I encounter enough of such scenarios, >> >> Put an image in relational table, so that each pixel would be a cell. >> Put a program code in a relational table and write compiler in SQL >> ... > > Why SQL? SQL is one of an infinite possible relational languages. Fine, show us an outline of a better language limited to solely relations and we'll see. >>> Further, relational does not dictate implementation. >> >> Wrong, it puts definite limits of the implementation. > > Show me a definite limit. 1. Row ID. It falls out of model, completely. In a truly relational model you cannot mark either cells or rows, they have no identity of their own. 2. Tables of tables. 3. Generic programming in terms of sets of tables sharing common properties. >>> If I am *searching* based on multiple factors, sure I'd be happy to use >>> a (good) table browser. >> >> That's the point, you need a different paradigm, because "path" is not a >> type in SQL. Because result sets aren't ordered in SQL, etc. Write a GPS >> car navigation system representing the results as relations and try to sell >> it *anybody*! > > Please clarify. > > BTW, here is a "road" schema: > > Table: Road > ----------- > roadID > roadTitle > roadType (Highway, Main, Side, Mixed, etc.) > > Table: Points > ------------- > pointID > Longit (longitude) > Lattit (lattitude) Referential GPS resolution is about 30cm horizontally. Let's take, say, a Germany map (not such a big country) with 30x30cm mesh... [Hint: roads have limited width.] > There are other, perhaps better, ways to do this. I added a "Point" > table so intersection info may be easier to represent. This is just a > quickie demo. .... of why this cannot work. Not to mention that GPS navigation system calculates from a stream of longitude, latitude, height, mileage, speed from the car, not only the road position, but relative positions of close objects and the direction you are driving. All this is done with a high level or error tolerance. GPS is very unreliable. Forgetting for a while, that searching the DB you proposed would require several days (years?) per query and a large truck to load the DB onto. Just write down a SELECT statement for the model above! > One of the biggest selling points of RDBMS is that multiple languages > can use them. You mean the languages, without which one couldn't be able to use these RDBMS. I don't see how relying on concurrent products makes yours any better... >>> Show with code. >> >> But you said that you aren't interested in static program correctness >> analysis. >> >> If you want a challenge, fine. Take any machine learning method. Training >> sets are ideal tables, rows and columns, nothing else. Take any method of >> your choice and implement it in SQL! For introduction to existing methods, >> see excellent tutorials by Andrew Moor: >> >> http://www.autonlab.org/tutorials/ > > How about something from the domain of custom biz apps. I have already > conceded out of ignorance of the domain that DB's may not be good for > heavy-duty numerical analysis. This is not numerical analysis. This a challenge to the relational approach in general. There is a problem specified relationally, that has an obvious relational solution, yet nobody would even try to use RDBMS for that. How could THAT happen? [ Answer: RDBMS are completely unsuitable either for matching in multidimensional spaces, or for best-match criteria. The idea of separating data and using normalized search schemas simply does not work beyond trivial cases. Now, you will tell me that all biz-applications are trivial, but I won't buy it. And for all I won't buy a tool limited to trivial cases! ] > Again, I don't expect SQL or relational to solve the *entire* problem > by itself. From this is derive that you consider relational is a niche solution for a limited number of problems. As such it cannot be a concurrent to OO. But actually, they are incomparable not because relational is incomplete and thus bad. It isn't bad. They are incomparable, because relational is of lower level. You cannot compare a vehicle with a wheel, though a circus rider could use the later. I, personally, better take a car. Some would a jet or ship. > But to give an analogy, program code is merely data to the > interpreter/compiler. I don't care about the CPU. > A developer may think of a function as > "behavior", but the interpreter treats it more like data if we look at > other processes that read what we normally call "data". That the point, software is developed, maintained and finally scraped by humans. >> One thing is quite clear, it is impossible even to define the term "data", >> without description of behavior. Look at mathematical definitions of >> numbers. >> >> "Data" is a set of computation states, characterized by definite behavior. > > Perhaps you should make a distinction between "is a set of" and "can be > defined as a set of". Claiming something "is" is a strong ascertion. For you, who believes in existence of data. To me, there is no data without something that interprets them exposing a behavior. There is no information without the receiver. >> When it is said that a table cell contains 1, it means all states where Get >> (or SELECT) would deliver result associated with the application domain >> object denoted as 1. >> >> It is the behavioral approach, which makes both OO and your beloved >> relational model *implementation-independent*. Otherwise, you were unable >> even to talk about "data", because, again, what in common have two states >> of magnetic fields on the hard drives of two computers? They expose same >> *behavior*, which you call "data"! Is big-endian and low-endian encoded >> 26732147 same "data"? > > Perhaps, but that is an implemention issue. There may be other ways to > implement it. Implement what? Again, there is no either data or implementation before you fix some setup. Once I change the setup, implementation becomes rubbish and data disappear. So the whole idea of extracting data is fundamentally wrong. Note that true relational is a way of data *abstraction*, not extraction (though on a lower level than ADT.) This is why I say that it does not withstand OO. Data separation indeed does, but it is not relational, it is just wrong. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |