SQL
in [OOP]
|
From: topmind on 3 Feb 2006 21:28 Dmitry A. Kazakov wrote: > On 2 Feb 2006 17:13:49 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > > >> 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.), > > This is a definition of a class: the set of types, each of them has "<", > "=". Further one might wish "<" to be order relation and "=" be equality > relation. You can argue that all objects should be of this type, but this > is mathematically unsound. For example, tables themselves, as objects, > aren't ordered. Complex numbers aren't ordered, etc. There also might be > incomparable objects. 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. > > > then relational can > > operate on it. (And possibly only just equal or not equal are needed. > > Need more pondering on this.) > > You need order for sorting, otherwise everything will become O(n). Sorting is a (nice) convenience of most RDBMS, but its not required for relational itself. (I had to face this issue when I designed the draft for SMEQL, my pet query language. I basically made it an "internal" operation.) > > > 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. > > Thank you for explaining why ADT is so great! (:-)) You are right, with ADT > one just need to implement the interface of a > thing-that-can-be-in-a-relational-table and here it is, the engine works! 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. > > >>> 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.). > > How else, you can extend the DB for dealing with something new without > changing the engine? > > You probably meant not new types, but new classes, new interfaces > additional to a thing-that-can-be-in-a-relational-table. But I don't see > why this should be any advantage. > Note that even for things you can put in > a table, it makes a lot of sense to refine interfaces to have: > integer-number-in-a-table with specific operations to sum a column, and > string-in-a-table, and so on. I am not following this. One does not need to distinquish between numbers and strings (internally) to have a language or expression. A fair amount of dynamic languages are like this. The language does not care about the difference between a number and a string, treating everything (or at least every scalar) as pretty much a string. An "add" function might care, but that is a content validation issue specific to *it*, not the base language. It may give an "operand not a valid number" error if it gets a funny string. The base language has no concept of types for numbers versus strings, only the library operations may care. > > >> 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? > > The only difference is "A1" (a run-time object of the type String) vs. A1 > (statically known name, not an object, not a type, nothing). The first can > be trivially typed as SQL does. There are two types: String and Table. The > second requires sets of types to be handled in a generic way. To bring it > back to the language. OO offers you both. SQL can only the first. When you > criticize OO, you refer to the second, which in the most of languages does > not allow any kind of generic programming, because A1 is just a name. But > OO does not force you to do so. Moreover OOA/D requires you to carefully > consider whether it is really just A1, the singleton, or there is a set of > values A1, A2, ..., you have to factor out. If somebody ignores good > advises, then it isn't a problem with OO. I agree that SQL is not "meta" enough. That is the fault of a specific language (SQL), not relational. However, I have not seen it near a big enough net problem to abandon existing RDBs for OO. Most shops don't like too many meta techniques anyhow (for good or bad), so even if it was available, it probably wouldn't improve popularity. 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). > > >> 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. > > Relational model is just a view. It might be formally correct, but > inappropriate for technical reasons, or because it just appears unnatural > for humans (like relational representation of graphs.) Relational does not dictate how a graph "looks". That is a display issue. However, I hardly see how OO is an improvement. "Unatural" for *which* humans? I've found over the years that everybody's head works differently. I won't claim that relational is objectively better for this reason. I just find it a good model/tool that fits close to the way I think. > OO model offers a > choice which IMO by no means excludes relational model. Well, that is part of the problem: Relational introduces discipline, conventions, and integrity. Navigational approaches perhaps are (arguably) a super-set, but that is why navignl. is so messy: NO DISCIPLINE. It is roughly analogous to Structured (nested blocks) programming versus GO TO's, where navigational is the Goto of structuring. Or as l like to say, "shanty town". (Nobody can objectively prove goto's worse or better also. Most arguments come down to human psychology. "Consistency" is perhaps an external metric, but tough to measure.) 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. 2. Relational generally assumes a partitioning between data and behavior, while OO tries to meld them. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T-
From: Dmitry A. Kazakov on 4 Feb 2006 07:26 On 3 Feb 2006 18:28:11 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> On 2 Feb 2006 17:13:49 -0800, topmind wrote: >> >>> 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.), >> >> This is a definition of a class: the set of types, each of them has "<", >> "=". Further one might wish "<" to be order relation and "=" be equality >> relation. You can argue that all objects should be of this type, but this >> is mathematically unsound. For example, tables themselves, as objects, >> aren't ordered. Complex numbers aren't ordered, etc. There also might be >> incomparable objects. > > 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. >>> then relational can >>> operate on it. (And possibly only just equal or not equal are needed. >>> Need more pondering on this.) >> >> You need order for sorting, otherwise everything will become O(n). > > Sorting is a (nice) convenience of most RDBMS, but its not required for > relational itself. (I had to face this issue when I designed the draft > for SMEQL, my pet query language. I basically made it an "internal" > operation.) Call it internal, that changes nothing. There must be an order to sort. The order have to be compatible with the equality relation above. But again all this in not essential. Important is only existence of an interface for a set of types. So all objects you place in a table must be at least from this class. And the point is that there are other interfaces, no less useful, beyond copyable, ordered types. >>> 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. >> >> Thank you for explaining why ADT is so great! (:-)) You are right, with ADT >> one just need to implement the interface of a >> thing-that-can-be-in-a-relational-table and here it is, the engine works! > > 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. >> How else, you can extend the DB for dealing with something new without >> changing the engine? >> >> You probably meant not new types, but new classes, new interfaces >> additional to a thing-that-can-be-in-a-relational-table. But I don't see >> why this should be any advantage. > >> Note that even for things you can put in >> a table, it makes a lot of sense to refine interfaces to have: >> integer-number-in-a-table with specific operations to sum a column, and >> string-in-a-table, and so on. > > I am not following this. One does not need to distinquish between > numbers and strings (internally) to have a language or expression. A > fair amount of dynamic languages are like this. The language does not > care about the difference between a number and a string, treating > everything (or at least every scalar) as pretty much a string. An "add" > function might care, but that is a content validation issue specific to > *it*, not the base language. It may give an "operand not a valid > number" error if it gets a funny string. The base language has no > concept of types for numbers versus strings, only the library > operations may care. 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. I leave the issues of safety aside. But even if you enjoy customer calls late night, nevertheless, the design above is flawed. There is not only the types of the operands. What is about the type of result? (example: time - time yields duration, but time!) What about summation of rows? What about adding distances to luminous flux? What about different kinds of "add"? (example: scalar multiplication vs. vector one, or, better, I'm sure, you are aware that floating-point arithmetic is unacceptable for money calculations, and fixed-point arithmetic for numeric analysis and scientific calculations.) Can I add a column to column? Can I add tables? Does this "add" have an inverse operation. When? Any "add" has inverse? Any type (sic!) has 0, -1? What is -1 of a column? [There is no universal arithmetic for all objects of any type (sic!) => there cannot be any universal engine to implement it.] All these issues are handled by the type system, and there is absolutely no contradiction to relational model. > 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. > Relational does not dictate how a graph "looks". That is a display > issue. However, I hardly see how OO is an improvement. Mathematically graph is a relation, but its representation as a table is not only unnatural for humans, but also utterly inefficient with respect of space and time required for may operations. > "Unatural" for *which* humans? I've found over the years that > everybody's head works differently. Well, next time visiting subway, take a look at its map on the wall and ask yourself if you really would like to have it depicted as an incidence matrix of stations... >> OO model offers a >> choice which IMO by no means excludes relational model. > > Well, that is part of the problem: Relational introduces discipline, > conventions, and integrity. Navigational approaches perhaps are > (arguably) a super-set, but that is why navignl. is so messy: NO > DISCIPLINE. It is roughly analogous to Structured (nested blocks) > programming versus GO TO's, where navigational is the Goto of > structuring. Or as l like to say, "shanty town". > (Nobody can objectively prove goto's worse or better also. Most > arguments come down to human psychology. "Consistency" is perhaps an > external metric, but tough to measure.) Ah, but types systems are far better with these issues. In SQL any integer is integer. The only difference is semantically irrelevant number of digits. In ADT I can have number of customers and number bug reports ensuring, that no any program would ever mix them. The problem of gotos is their power. They have too big "norm". Mathematically, small program changes may lead to an enormous, unpredictable effects. 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. 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. > 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. > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 4 Feb 2006 18:28 Dmitry A. Kazakov wrote: > On 3 Feb 2006 18:28:11 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 2 Feb 2006 17:13:49 -0800, topmind wrote: > >> > >>> 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.), > >> > >> This is a definition of a class: the set of types, each of them has "<", > >> "=". Further one might wish "<" to be order relation and "=" be equality > >> relation. You can argue that all objects should be of this type, but this > >> is mathematically unsound. For example, tables themselves, as objects, > >> aren't ordered. Complex numbers aren't ordered, etc. There also might be > >> incomparable objects. > > > > 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. > > >>> then relational can > >>> operate on it. (And possibly only just equal or not equal are needed. > >>> Need more pondering on this.) > >> > >> You need order for sorting, otherwise everything will become O(n). > > > > Sorting is a (nice) convenience of most RDBMS, but its not required for > > relational itself. (I had to face this issue when I designed the draft > > for SMEQL, my pet query language. I basically made it an "internal" > > operation.) > > Call it internal, that changes nothing. There must be an order to sort. The > order have to be compatible with the equality relation above. But again all > this in not essential. Perhaps. Sorting is a nice feature when we *do* have ordering to a given notation/math/domain. However, it does not have to be part of relational to be provided as a service. > Important is only existence of an interface for a > set of types. So all objects you place in a table must be at least from > this class. And the point is that there are other interfaces, no less > useful, beyond copyable, ordered types. Again, having a feature and being a thing (such as a class) are different leaps. > > >>> 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. > >> > >> Thank you for explaining why ADT is so great! (:-)) You are right, with ADT > >> one just need to implement the interface of a > >> thing-that-can-be-in-a-relational-table and here it is, the engine works! > > > > 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. > > >> How else, you can extend the DB for dealing with something new without > >> changing the engine? > >> > >> You probably meant not new types, but new classes, new interfaces > >> additional to a thing-that-can-be-in-a-relational-table. But I don't see > >> why this should be any advantage. > > > >> Note that even for things you can put in > >> a table, it makes a lot of sense to refine interfaces to have: > >> integer-number-in-a-table with specific operations to sum a column, and > >> string-in-a-table, and so on. > > > > I am not following this. One does not need to distinquish between > > numbers and strings (internally) to have a language or expression. A > > fair amount of dynamic languages are like this. The language does not > > care about the difference between a number and a string, treating > > everything (or at least every scalar) as pretty much a string. An "add" > > function might care, but that is a content validation issue specific to > > *it*, not the base language. It may give an "operand not a valid > > number" error if it gets a funny string. The base language has no > > concept of types for numbers versus strings, only the library > > operations may care. > > 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. 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. > I > leave the issues of safety aside. But even if you enjoy customer calls late > night, nevertheless, the design above is flawed. There is not only the > types of the operands. What is about the type of result? (example: time - > time yields duration, but time!) What about summation of rows? What about > adding distances to luminous flux? What about different kinds of "add"? > (example: scalar multiplication vs. vector one, or, better, I'm sure, you > are aware that floating-point arithmetic is unacceptable for money > calculations, and fixed-point arithmetic for numeric analysis and > scientific calculations.) Can I add a column to column? Can I add tables? > Does this "add" have an inverse operation. When? Any "add" has inverse? Any > type (sic!) has 0, -1? What is -1 of a column? [There is no universal > arithmetic for all objects of any type (sic!) => there cannot be any > universal engine to implement it.] > > All these issues are handled by the type system, and there is absolutely no > contradiction to relational model. I agree they are generally orthogonal. The rules of the "expression engine" don't have to be relational's care. > > > 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.) > > > Relational does not dictate how a graph "looks". That is a display > > issue. However, I hardly see how OO is an improvement. > > Mathematically graph is a relation, but its representation as a table is > not only unnatural for humans, It depends. With a good table-browser and query system, tables are pretty good at navigating such info once you get used to it. I agree it takes practice to work effectively with table browsing and querying, but the best techniques in the longer run are sometimes not the easiest to start with. The problem with "box and arrow" type of graphical displays is that it has proven difficult to display link info and node (box) details at the same time. And, if you have more than 3 or so factors it becomes too difficult to turn into a 2D display. Many things have dozens of factor spaces associated with them. The human visual system cannot handle more than 3 dimensions and thus is inappropriate for large factor space. > but also utterly inefficient with respect of > space and time required for may operations. When I encounter enough of such scenarios, I'll stop using it. So far, not. Further, relational does not dictate implementation. A relational engine can probably constructed for a specific purpose such that we don't have to learn a new paradigm or interface. > > > "Unatural" for *which* humans? I've found over the years that > > everybody's head works differently. > > Well, next time visiting subway, take a look at its map on the wall and ask > yourself if you really would like to have it depicted as an incidence > matrix of stations... If I am *searching* based on multiple factors, sure I'd be happy to use a (good) table browser. Physical maps show location, but not factors. Nor does it preclude the use of physical maps when location info is desired. > > >> OO model offers a > >> choice which IMO by no means excludes relational model. > > > > Well, that is part of the problem: Relational introduces discipline, > > conventions, and integrity. Navigational approaches perhaps are > > (arguably) a super-set, but that is why navignl. is so messy: NO > > DISCIPLINE. It is roughly analogous to Structured (nested blocks) > > programming versus GO TO's, where navigational is the Goto of > > structuring. Or as l like to say, "shanty town". > > > (Nobody can objectively prove goto's worse or better also. Most > > arguments come down to human psychology. "Consistency" is perhaps an > > external metric, but tough to measure.) > > Ah, but types systems are far better with these issues. In SQL any integer > is integer. The only difference is semantically irrelevant number of > digits. In ADT I can have number of customers and number bug reports > ensuring, that no any program would ever mix them. Again, I don't want to get into a dynamic-vs-static typing debate. There are plenty of them already at c2 and usenet. It appears to be a personal preference or domain-specific decision. I prefer dynamic or type-free typing systems for the domain I work in. Flexibility and adaptability is more important than having the compiler check as much as possible up-front in my observation. Static domains are moving overseas where cheaper labor makes it more cost effective to spend effort on the verbosity and nit-pickiness needed by strong compiler-time checking languages. The comparative advantage of the US is in trend-hopping, and static types don't work well there. 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. > > 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. Plus, I have not seen any objective proof of that, regardless of what my personal preferences are. I have seen messy "structured" code also. It is hard to provide an objective test to know if the problem is with the coder or the goto. > 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? Much of the stuff that you think is domain-specific is really just "database verbs" in disquise I bet. > > 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. > > > 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. > > > 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. This would get into a definition battle that has no hard math to say yeah or neah. Relational provides fairly consistent rules and conventions for organizing boatloads of stuff. ADT's don't. In particular they don't provide any disciplined or consistent way to link stuff, focusing on thing-at-a-time instead of the bigger pool of stuff. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T-
From: Dmitry A. Kazakov on 5 Feb 2006 09:30 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. >> Call it internal, that changes nothing. There must be an order to sort. The >> order have to be compatible with the equality relation above. But again all >> this in not essential. > > Perhaps. Sorting is a nice feature when we *do* have ordering to a > given notation/math/domain. However, it does not have to be part of > relational to be provided as a service. Theoretically yes, but impracticable. This is a serious problem for container libraries design. [In fact RDB is simply a specialized container] Nobody wants O(n) containers, but for many types one might wish to have unordered sets, even if there is no reasonable order. One tries to invent order (making checksum, or comparing addresses), but an invented order leads to nasty surprises. I have had a pair of horror stories. >> Important is only existence of an interface for a >> set of types. So all objects you place in a table must be at least from >> this class. And the point is that there are other interfaces, no less >> useful, beyond copyable, ordered types. > > Again, having a feature and being a thing (such as a class) are > different leaps. It is a philosophical question. In my subjective idealistic philosophy it is exactly same. >>> 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. >> 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. > 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. 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". >>> 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 >> 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 .... > Further, relational does not dictate implementation. Wrong, it puts definite limits of the implementation. > 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*! > 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. >> 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! >> 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/ 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... >>> 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". > 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. 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"? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Patrick May on 5 Feb 2006 11:50
"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. 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? > > > > 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, it is less capable of reflecting the abstractions of problem domains other than those of 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? > > 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. > > 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. > > 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. > > 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, the functionality provided by Kerberos cannot be provided simply through the use of ACLs. 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. Sincerely, Patrick P.S. I note that you removed all reference to your numerous other unsubstantiated claims in this thread. May I assume from this that you have retracted them all? ------------------------------------------------------------------------ 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) |