SQL
in [OOP]
|
From: Dmitry A. Kazakov on 9 Feb 2006 04:16 On 8 Feb 2006 17:04:18 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> On 7 Feb 2006 18:04:08 -0800, topmind wrote: >> >>> Dmitry A. Kazakov wrote: >>>> On 6 Feb 2006 19:32:11 -0800, topmind wrote: > >>> The context was "configurable" integers. You are using the >>> out-of-the-box 8-byte version here, not configurable ones. >> >> Replace the first line with: >> >> type I is range -223452345..234234234; > > That is a language-specific feature. Yes, we are talking about features of languages. This is a feature, SQL does not have. >> Now show me a relational equivalent! > > "Cell types" are generally orthogonal to the relational model. > Relational only cares that the "expression engine" follow a minimum set > of rules, as already described. Thus, your question is outside of > relational. That was your question, by the way. You claimed, I quote: "I don't have to define and hunt down definitions of types." This is wrong, I gave an implementation with a pre-defined integer type which also does not define any new type. This didn't satisfy you and you switched to: "You are using the out-of-the-box 8-byte version here, not configurable ones." I showed that modern languages have no problem with defining new integer types. [SQL is unable to do this.] So, what is your point? That cell types can be any? This is wrong, they have to be at least copyable and comparable. That relational is defined on this class of types? This was my starting point. > Further, most commercial RDBMS have a "money" or "decimal" type such > that one does not have to use floating. Come on, already elementary statistical analysis cannot be performed in fixed-point, because of massive precision loss in division. It is a to death beaten issue. There is no numeric type for all purposes. And, please, don't tell me that biz-applications don't do statistics, linear programming and other optimization problems, or anything that requires division. >>> Floating point tends to stink for biz apps, >> >> Rubbish. What stinks is lack of understanding differences between numeric >> models and missing contracts specifying the *semantics* of numeric >> operations. > > How would putting a wrapper around them fix the above problem you > mention? Not a wrapper, but another implementation of. With ADT I can have any numeric model and use relational or any other containers independently on that. Again: the whole relational is no more than a specialized container type. It is *not* a paradigm. >> 2. It is a paradigm in question. A paradigm should be capable to decompose >> any problem. > > I disagree with such a definition! I buy into Yin-Yang *complimentary* > use of *multiple* tools. One-size-fits-all is old-style and multi-tool > usage is on the increase. Using tools has nothing to do with decomposition. Basically, any program can be written using solely the keyboard. Imagine a keyboard vendor comparing keyboards (easy to use, 101 keys!), with OO (boring, much to learn). What about "keyboard paradigm"? Yin-Yang? (:-)) > Show me relational being limiting to my domain. It is enough, that it limits *my* domain! >>>> No, we wish to model them as relations! Polygon isn't a relation. You can >>>> have a table of rows representing polygons, that's OK. Now, write the >>>> SELECT statement that gives me the car position, movement direction and >>>> distance to the next turn I have to do. Show, how this problem can be >>>> decomposed using relational approach. >>> >>> Use the distance formula to find the nearest matches. The rest is left >>> as a reader excercise. >> >> No that will extract the whole table and sort it by the distance! Many >> thanks! > > ...And Distance < myThreashold > > Most SQL dielects also let one limit the number of rows returned. This changes nothing. The result is *sorted*. To sort using some *external* key you have to visit *all* rows. This is at least O(n). It seems that you don't well understand the background. Read, for example: http://en.wikipedia.org/wiki/Space_partitioning >>> [pixel example] > >>> Relational does not dictate implementation. Yes, it means you may have >>> to have custom programmed RDBMS engines to get the most compact >>> representation possible, but that will be the case no matter what you >>> use. >> >> Stop here. "Custom" in "custom programmed RDBMS engine" means >> non-relationally programmed. Am I right? > > Heck no! A custom made/tuned relational engine is certainly as possible > as making a non-relational one. A non-trivial commercial graphics > engine will almost certain be custom-built for graphics regardless of > paradigm used. No, I meant the paradigm used to *implement* that custom engine. To make it simpler: will it be programmed in SQL? Carefully consider your answer. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 11 Feb 2006 02:10 Dmitry A. Kazakov wrote: > On 8 Feb 2006 17:04:18 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > >> On 7 Feb 2006 18:04:08 -0800, topmind wrote: > >> > >>> Dmitry A. Kazakov wrote: > >>>> On 6 Feb 2006 19:32:11 -0800, topmind wrote: > > > >>> The context was "configurable" integers. You are using the > >>> out-of-the-box 8-byte version here, not configurable ones. > >> > >> Replace the first line with: > >> > >> type I is range -223452345..234234234; > > > > That is a language-specific feature. > > Yes, we are talking about features of languages. This is a feature, SQL > does not have. What is your point? SQL lacks a lot of stuff. Some app langs have range declarations, some don't. Same with relational languages. > > >> Now show me a relational equivalent! > > > > "Cell types" are generally orthogonal to the relational model. > > Relational only cares that the "expression engine" follow a minimum set > > of rules, as already described. Thus, your question is outside of > > relational. > > That was your question, by the way. You claimed, I quote: > > "I don't have to define and hunt down definitions of types." I think this was not in the context of relational. > > This is wrong, I gave an implementation with a pre-defined integer type > which also does not define any new type. This didn't satisfy you and you > switched to: > > "You are using the out-of-the-box 8-byte version here, not configurable > ones." > > I showed that modern languages have no problem with defining new integer > types. [SQL is unable to do this.] I don't think I would call that feature a "type". A "constraint" perhaps. Or even a "trigger", similar to DB triggers, but for variables instead. > > So, what is your point? That cell types can be any? This is wrong, they > have to be at least copyable and comparable. That relational is defined on > this class of types? This was my starting point. Sorry, but I don't see the practical significence of that from an application perspective. > > > Further, most commercial RDBMS have a "money" or "decimal" type such > > that one does not have to use floating. > > Come on, already elementary statistical analysis cannot be performed in > fixed-point, because of massive precision loss in division. It is a to > death beaten issue. There is no numeric type for all purposes. I did not claim there was. > > And, please, don't tell me that biz-applications don't do statistics, > linear programming and other optimization problems, or anything that > requires division. I didn't. > > >>> Floating point tends to stink for biz apps, > >> > >> Rubbish. What stinks is lack of understanding differences between numeric > >> models and missing contracts specifying the *semantics* of numeric > >> operations. > > > > How would putting a wrapper around them fix the above problem you > > mention? > > Not a wrapper, but another implementation of. With ADT I can have any > numeric model and use relational or any other containers independently on > that. Again: the whole relational is no more than a specialized container > type. It is *not* a paradigm. Same with the type-free approach. If you want a big number, no problem: x = 2342423423412342343423423.23342039480934509243 Same as x = "2342423423412342343423423.23342039480934509243" Now, whether a given function(s) can handle such a number is another matter. A string-based decimal library can. > > >> 2. It is a paradigm in question. A paradigm should be capable to decompose > >> any problem. > > > > I disagree with such a definition! I buy into Yin-Yang *complimentary* > > use of *multiple* tools. One-size-fits-all is old-style and multi-tool > > usage is on the increase. > > Using tools has nothing to do with decomposition. > > Basically, any program can be written using solely the keyboard. Imagine a > keyboard vendor comparing keyboards (easy to use, 101 keys!), with OO > (boring, much to learn). What about "keyboard paradigm"? Yin-Yang? (:-)) Your analogy is too extreme to be useful. My point is that your definition makes a huge assumption about the usefulness of specialization. > > > Show me relational being limiting to my domain. > > It is enough, that it limits *my* domain! I think you just remember the parts of your apps where it does not work. I bet behind most mega number crunching or special-purpose processing engines is a database or the need for a database to track input and output sources, input/output items, and/or processing sets, runs, or schedules of runs. For example, who ran it, why it was run, who paid for it, how long it ran, what were the inputs and outputs, where are the inputs and outputs kept, etc. > > >>>> No, we wish to model them as relations! Polygon isn't a relation. You can > >>>> have a table of rows representing polygons, that's OK. Now, write the > >>>> SELECT statement that gives me the car position, movement direction and > >>>> distance to the next turn I have to do. Show, how this problem can be > >>>> decomposed using relational approach. > >>> > >>> Use the distance formula to find the nearest matches. The rest is left > >>> as a reader excercise. > >> > >> No that will extract the whole table and sort it by the distance! Many > >> thanks! > > > > ...And Distance < myThreashold > > > > Most SQL dielects also let one limit the number of rows returned. > > This changes nothing. The result is *sorted*. To sort using some *external* > key you have to visit *all* rows. This is at least O(n). It seems that you > don't well understand the background. Read, for example: > > http://en.wikipedia.org/wiki/Space_partitioning I see nothing that keeps an RDBMs engine from using such techniques to speed up spacial queries. > > >>> [pixel example] > > > >>> Relational does not dictate implementation. Yes, it means you may have > >>> to have custom programmed RDBMS engines to get the most compact > >>> representation possible, but that will be the case no matter what you > >>> use. > >> > >> Stop here. "Custom" in "custom programmed RDBMS engine" means > >> non-relationally programmed. Am I right? > > > > Heck no! A custom made/tuned relational engine is certainly as possible > > as making a non-relational one. A non-trivial commercial graphics > > engine will almost certain be custom-built for graphics regardless of > > paradigm used. > > No, I meant the paradigm used to *implement* that custom engine. To make it > simpler: will it be programmed in SQL? Carefully consider your answer. Probably not. Relational has not yet proven very effective at being a key part of lower-level systems software. > > -- > Regards, > Dmitry A. Kazakov
From: Dmitry A. Kazakov on 11 Feb 2006 06:44 On 10 Feb 2006 23:10:35 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> Yes, we are talking about features of languages. This is a feature, SQL >> does not have. > > What is your point? SQL lacks a lot of stuff. Some app langs have range > declarations, some don't. Same with relational languages. The point is that they are typed, because types are useful. >> This is wrong, I gave an implementation with a pre-defined integer type >> which also does not define any new type. This didn't satisfy you and you >> switched to: >> >> "You are using the out-of-the-box 8-byte version here, not configurable >> ones." >> >> I showed that modern languages have no problem with defining new integer >> types. [SQL is unable to do this.] > > I don't think I would call that feature a "type". A "constraint" > perhaps. If you add X with one constraint to Y with other constraint and what would be the constraint of the result? >> So, what is your point? That cell types can be any? This is wrong, they >> have to be at least copyable and comparable. That relational is defined on >> this class of types? This was my starting point. > > Sorry, but I don't see the practical significence of that from an > application perspective. So we can agree that from theoretical point of view relational is not a paradigm, but a case. A for practice, this has a direct implication. With proper ADTs I can have a relational container library and forget about that nasty SQL and clumsy, slow, buggy RDBMSs. >>> Further, most commercial RDBMS have a "money" or "decimal" type such >>> that one does not have to use floating. >> >> Come on, already elementary statistical analysis cannot be performed in >> fixed-point, because of massive precision loss in division. It is a to >> death beaten issue. There is no numeric type for all purposes. > > I did not claim there was. No, you keep on trying to say that numeric types aren't necessary. This could only be true, if there were a universal numeric type (which you call "no type".) It is a clear contradiction with: > Same with the type-free approach. If you want a big number, no problem: > > x = 2342423423412342343423423.23342039480934509243 > > Same as > > x = "2342423423412342343423423.23342039480934509243" > > Now, whether a given function(s) can handle such a number is another > matter. A string-based decimal library can. See above. You still don't understand that number is not a chain of digits or a set of bits. Number is a type having various properties. I don't need numbers if it is unknown how to handle them. Please: compute "1"/"3" in your library! Again: for any library you have, I can find a counter example where it will not work. It is a hard mathematical *fact*. >>> Show me relational being limiting to my domain. >> >> It is enough, that it limits *my* domain! > > I think you just remember the parts of your apps where it does not > work. I bet behind most mega number crunching or special-purpose > processing engines is a database or the need for a database to track > input and output sources, input/output items, and/or processing sets, > runs, or schedules of runs. For example, who ran it, why it was run, > who paid for it, how long it ran, what were the inputs and outputs, > where are the inputs and outputs kept, etc. Of course no. We provide DB support only upon customer request, and only off-line. There is no DB capable to handle periodic data at 10-100ms rate. Then because data sources are asynchronous, relational representation of multi-channel data is rubbish. Furthermore, a medium-sized system has about 10,000 channels. Processing these data in a RDBMS would take days, while one hour of downtime costs dozens of kilobucks. So DB if used, then only for overall results and reports. >> This changes nothing. The result is *sorted*. To sort using some *external* >> key you have to visit *all* rows. This is at least O(n). It seems that you >> don't well understand the background. Read, for example: >> >> http://en.wikipedia.org/wiki/Space_partitioning > > I see nothing that keeps an RDBMs engine from using such techniques to > speed up spacial queries. O(n) >>>>> Relational does not dictate implementation. Yes, it means you may have >>>>> to have custom programmed RDBMS engines to get the most compact >>>>> representation possible, but that will be the case no matter what you >>>>> use. >>>> >>>> Stop here. "Custom" in "custom programmed RDBMS engine" means >>>> non-relationally programmed. Am I right? >>> >>> Heck no! A custom made/tuned relational engine is certainly as possible >>> as making a non-relational one. A non-trivial commercial graphics >>> engine will almost certain be custom-built for graphics regardless of >>> paradigm used. >> >> No, I meant the paradigm used to *implement* that custom engine. To make it >> simpler: will it be programmed in SQL? Carefully consider your answer. > > Probably not. Relational has not yet proven very effective at being a > key part of lower-level systems software. = you cannot decompose custom problems into relational. q.e.d. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 11 Feb 2006 15:54 Dmitry A. Kazakov wrote: > On 10 Feb 2006 23:10:35 -0800, topmind wrote: > > > Dmitry A. Kazakov wrote: > > >> Yes, we are talking about features of languages. This is a feature, SQL > >> does not have. > > > > What is your point? SQL lacks a lot of stuff. Some app langs have range > > declarations, some don't. Same with relational languages. > > The point is that they are typed, because types are useful. Well, I think it is a definition game being played here. Anyhow, being useful for A does not necessarily extrapolate to B. I agree that systems software may be a place where "types" are fairly useful. > > >> This is wrong, I gave an implementation with a pre-defined integer type > >> which also does not define any new type. This didn't satisfy you and you > >> switched to: > >> > >> "You are using the out-of-the-box 8-byte version here, not configurable > >> ones." > >> > >> I showed that modern languages have no problem with defining new integer > >> types. [SQL is unable to do this.] > > > > I don't think I would call that feature a "type". A "constraint" > > perhaps. > > If you add X with one constraint to Y with other constraint and what would > be the constraint of the result? I am not sure what you are asking. Please attempt to reword it. > > >> So, what is your point? That cell types can be any? This is wrong, they > >> have to be at least copyable and comparable. That relational is defined on > >> this class of types? This was my starting point. > > > > Sorry, but I don't see the practical significence of that from an > > application perspective. > > So we can agree that from theoretical point of view relational is not a > paradigm, but a case. No. Interchangle implementation does not change anything. For example, an FP language can be written in an OOP language/style and visa versa. That does not mean that one is a "subset" of the other. It is just Turing Equivalency at work. I suppose you will reply that relational is not Turing Complete. It does not need to be. Your equivalency criteria has been shown to be faulty in out outside of relational or SQL. > A for practice, this has a direct implication. With > proper ADTs I can have a relational container library and forget about that > nasty SQL and clumsy, slow, buggy RDBMSs. So something tested by an internal QA team and hundreds of thousands of users is going to be more buggy than something you roll your own in a few months? I highly doubt it. > > >>> Further, most commercial RDBMS have a "money" or "decimal" type such > >>> that one does not have to use floating. > >> > >> Come on, already elementary statistical analysis cannot be performed in > >> fixed-point, because of massive precision loss in division. It is a to > >> death beaten issue. There is no numeric type for all purposes. > > > > I did not claim there was. > > No, you keep on trying to say that numeric types aren't necessary. This > could only be true, if there were a universal numeric type (which you call > "no type".) It is a clear contradiction with: > > > Same with the type-free approach. If you want a big number, no problem: > > > > x = 2342423423412342343423423.23342039480934509243 > > > > Same as > > > > x = "2342423423412342343423423.23342039480934509243" > > > > Now, whether a given function(s) can handle such a number is another > > matter. A string-based decimal library can. > > See above. You still don't understand that number is not a chain of digits > or a set of bits. Number is a type having various properties. I don't need > numbers if it is unknown how to handle them. Not "unknown" but rather "situational". You are thinking in "is-a" mode. These kinds of numbers don't carry around a "type flag" that says only a given set of operations can be used on it. > Please: compute "1"/"3" in > your library! Ideally the library would have a decimal limitation parameter and I believe dedicated decimal packages do. It may resemble: x = divide(a, b, 20) Here the last parameter would be the max number of decimals (twenty). However, the "built in" division operator usually has pre-set limit. If you don't like the pre-set limit, then use a library like above. (The downsides of infix operators is that extra or optional (named) parameters are not easy to add.) > > Again: for any library you have, I can find a counter example where it will > not work. It is a hard mathematical *fact*. I am not sure what your point is. Are you saying you can find a way to break stuff? That just puts you on par with a Russian hacker. > > >>> Show me relational being limiting to my domain. > >> > >> It is enough, that it limits *my* domain! > > > > I think you just remember the parts of your apps where it does not > > work. I bet behind most mega number crunching or special-purpose > > processing engines is a database or the need for a database to track > > input and output sources, input/output items, and/or processing sets, > > runs, or schedules of runs. For example, who ran it, why it was run, > > who paid for it, how long it ran, what were the inputs and outputs, > > where are the inputs and outputs kept, etc. > > Of course no. We provide DB support only upon customer request, and only > off-line. There is no DB capable to handle periodic data at 10-100ms rate. > Then because data sources are asynchronous, relational representation of > multi-channel data is rubbish. Furthermore, a medium-sized system has about > 10,000 channels. Processing these data in a RDBMS would take days, while > one hour of downtime costs dozens of kilobucks. So DB if used, then only > for overall results and reports. If RDBMS don't work for your niche for whatever reason, then so be it. > > >> This changes nothing. The result is *sorted*. To sort using some *external* > >> key you have to visit *all* rows. This is at least O(n). It seems that you > >> don't well understand the background. Read, for example: > >> > >> http://en.wikipedia.org/wiki/Space_partitioning > > > > I see nothing that keeps an RDBMs engine from using such techniques to > > speed up spacial queries. > > O(n) This is only for your "external key" assumption. A custom engine does not have to use that. A relational interface does not dictate implementation. If dead Girbals can be used to make it run certain kinds of operations faster, then go for it. A relational-intended "expression engine" could have a DistanceBetween(locatID1, locatID2) operation that uses whatever the best implementation is for such. > > >>>>> Relational does not dictate implementation. Yes, it means you may have > >>>>> to have custom programmed RDBMS engines to get the most compact > >>>>> representation possible, but that will be the case no matter what you > >>>>> use. > >>>> > >>>> Stop here. "Custom" in "custom programmed RDBMS engine" means > >>>> non-relationally programmed. Am I right? > >>> > >>> Heck no! A custom made/tuned relational engine is certainly as possible > >>> as making a non-relational one. A non-trivial commercial graphics > >>> engine will almost certain be custom-built for graphics regardless of > >>> paradigm used. > >> > >> No, I meant the paradigm used to *implement* that custom engine. To make it > >> simpler: will it be programmed in SQL? Carefully consider your answer. > > > > Probably not. Relational has not yet proven very effective at being a > > key part of lower-level systems software. > > you cannot decompose custom problems into relational. Yes you can. It is a similar issue as the Turing Tarpit. Some things do it well, some do it poorly. > > q.e.d. b.s. > > -- > Regards, > Dmitry A. Kazakov -T-
From: Dmitry A. Kazakov on 12 Feb 2006 05:59
On 11 Feb 2006 12:54:38 -0800, topmind wrote: > Dmitry A. Kazakov wrote: >> On 10 Feb 2006 23:10:35 -0800, topmind wrote: >> > Well, I think it is a definition game being played here. Anyhow, being > useful for A does not necessarily extrapolate to B. I agree that > systems software may be a place where "types" are fairly useful. No, they are useful for software in general. Even SQL cannot avoid them. >>>> This is wrong, I gave an implementation with a pre-defined integer type >>>> which also does not define any new type. This didn't satisfy you and you >>>> switched to: >>>> >>>> "You are using the out-of-the-box 8-byte version here, not configurable >>>> ones." >>>> >>>> I showed that modern languages have no problem with defining new integer >>>> types. [SQL is unable to do this.] >>> >>> I don't think I would call that feature a "type". A "constraint" >>> perhaps. >> >> If you add X with one constraint to Y with other constraint and what would >> be the constraint of the result? > > I am not sure what you are asking. Please attempt to reword it. That was your idea to separate types and constraints, or? So was my question. [ Constraints are applied to types. Constrained types are subtypes. In general it is called specialization. ] >>>> So, what is your point? That cell types can be any? This is wrong, they >>>> have to be at least copyable and comparable. That relational is defined on >>>> this class of types? This was my starting point. >>> >>> Sorry, but I don't see the practical significence of that from an >>> application perspective. >> >> So we can agree that from theoretical point of view relational is not a >> paradigm, but a case. > > No. Please don't elude, practical issues were addressed in the following paragraph. >> A for practice, this has a direct implication. With >> proper ADTs I can have a relational container library and forget about that >> nasty SQL and clumsy, slow, buggy RDBMSs. > > So something tested by an internal QA team and hundreds of thousands of > users is going to be more buggy than something you roll your own in a > few months? Carefully re-read the paragraph above. It says nothing about who will develop that library. The word "library" implies reuse, right? RDBMS exist only because in 70s there were no languages capable to provide a relational library. A desire to have it integrated into *normal* languages would become obvious, if we consider embedded SQL. Since then nobody of sound mind could even imagine SQL in place of a universal-purpose language. >>>>> Further, most commercial RDBMS have a "money" or "decimal" type such >>>>> that one does not have to use floating. >>>> >>>> Come on, already elementary statistical analysis cannot be performed in >>>> fixed-point, because of massive precision loss in division. It is a to >>>> death beaten issue. There is no numeric type for all purposes. >>> >>> I did not claim there was. >> >> No, you keep on trying to say that numeric types aren't necessary. This >> could only be true, if there were a universal numeric type (which you call >> "no type".) It is a clear contradiction with: >> >>> Same with the type-free approach. If you want a big number, no problem: >>> >>> x = 2342423423412342343423423.23342039480934509243 >>> >>> Same as >>> >>> x = "2342423423412342343423423.23342039480934509243" >>> >>> Now, whether a given function(s) can handle such a number is another >>> matter. A string-based decimal library can. >> >> See above. You still don't understand that number is not a chain of digits >> or a set of bits. Number is a type having various properties. I don't need >> numbers if it is unknown how to handle them. > > Not "unknown" but rather "situational". Situation determines the semantics of "+" is exactly same as: situation determines the type. This changes nothing. > You are thinking in "is-a" > mode. These kinds of numbers don't carry around a "type flag" that says > only a given set of operations can be used on it. So, the flag carries "situation", and, what is changed? >> Please: compute "1"/"3" in >> your library! > > Ideally the library would have a decimal limitation parameter and I > believe dedicated decimal packages do. It may resemble: > > x = divide(a, b, 20) Excellent, why not x = divide(a, b, 21) Note that the value 20 vs. 21, 22, 23... and the very semantics of "divide" [truncation to n decimal digits] constitute a numeric type. This model is called fixed-point arithmetic. And there are zillions of applications where fixed-point is unacceptable. Unacceptable reads: with *any* realistic value of n. >> Again: for any library you have, I can find a counter example where it will >> not work. It is a hard mathematical *fact*. > > I am not sure what your point is. We better close this topic. Recommended reading: http://en.wikipedia.org/wiki/Category:Computer_arithmetic http://en.wikipedia.org/wiki/Rational_numbers http://en.wikipedia.org/wiki/Fixed-point http://en.wikipedia.org/wiki/Bignum http://en.wikipedia.org/wiki/Floating_point http://en.wikipedia.org/wiki/Interval_arithmetic http://www.cs.utep.edu/interval-comp/main.html >>>> This changes nothing. The result is *sorted*. To sort using some *external* >>>> key you have to visit *all* rows. This is at least O(n). It seems that you >>>> don't well understand the background. Read, for example: >>>> >>>> http://en.wikipedia.org/wiki/Space_partitioning >>> >>> I see nothing that keeps an RDBMs engine from using such techniques to >>> speed up spacial queries. >> >> O(n) > > This is only for your "external key" assumption. A custom engine does > not have to use that. A relational interface does not dictate > implementation. I don't care about interface, give me a relational *implementation*! [ As for interfaces, I already proposed to reissue all maps in the form of tables. You weren't much impressed. ] > If dead Girbals can be used to make it run certain > kinds of operations faster, then go for it. > > A relational-intended "expression engine" could have a > DistanceBetween(locatID1, locatID2) operation that uses whatever the > best implementation is for such. LOL! Dear topmind, it is O(n) with *any* implementation of DistanceBetween! >> you cannot decompose custom problems into relational. > > Yes you can. It is a similar issue as the Turing Tarpit. Some things do > it well, some do it poorly. Right. For the problems I have presented, relational doesn't work. This is all I wished to say. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |